Re: Any info about "Thread has exited with code 32772 (0x8004)"?
![Scott McPhillips [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Scott McPhillips [MVP]
news:Xns9A42BBA39C7...@193.202.122.102...
> Hi
> I did a simple dialog aplication using VC6 and I got that exit code.
> The program ' ' has exited with code 32772 (0x8004).
> I tried Error Lookup tool but didnt find anything about it.
>
> What this error code means?.
>
> Thanks in advance.
An exit code is defined by the program, not by Windows. That means it is
not necessarily an error, and it also means that Windows cannot tell you
what it means. It is up to the program. In an MFC program the exit code is
the value returned by CWinApp::ExitInsance.
--
Scott McPhillips [VC++ MVP]
Tom Serface
unhandled exception is occurring. My guess is something in some library is
exiting for you because some condition is not right.
Tom
Joseph M. Newcomer
completely arbitrary and typically totally meaningless value. Does your program run
correctly? If it does, ignore this message (I pay no attention whatsoever to the exit
codes of threads or processes, and haven't since I started programming Windows in 1990)
joe
On 12 Feb 2008 17:29:06 GMT, "-Nivel-" <ab...@fghij.klm> wrote:
>Hi
>I did a simple dialog aplication using VC6 and I got that exit code.
>The program ' ' has exited with code 32772 (0x8004).
>I tried Error Lookup tool but didnt find anything about it.
>
>What this error code means?.
>
>Thanks in advance.
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
joe
On 12 Feb 2008 22:25:54 GMT, "-Nivel-" <ab...@fghij.klm> wrote:
>"Tom Serface":
><news:AEFF6B79-FB06-4617...@microsoft.com> mas o menos el
>mar, 12 feb 2008 19:39:02 GMT
>Is something strange, when I close the dialog with a buttom that execute
>OnClose(); exit code in debug window is 0x0 as expected.
>But when I use "Close" from a menu I get that code.
>
>Last thing I discover is that is not an error code, it is the ID of that
>menu item. Don't know why the application is returning menu ID.
>
>
>thanks again.
David Ching
news:rr74r3tvruce23h93...@4ax.com...
> Why should it matter in the slightest? I consider the "exit code" to be
> essentially noise
It's not if you are running scripts which depend on the return value to
indicate success or failure. Many Windows OS command-line programs do not
return the proper error code.
-- David
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVvzhOQGbT9K0Re6Qg-OU4VGuHq0tAdTu01YlmIjUGm6t_o8g=s40-c)
Doug Harrison [MVP]
>Is something strange, when I close the dialog with a buttom that execute
>OnClose(); exit code in debug window is 0x0 as expected.
>But when I use "Close" from a menu I get that code.
>
>Last thing I discover is that is not an error code, it is the ID of that
>menu item. Don't know why the application is returning menu ID.
The return code comes from the return value of ExitInstance(), which by
default, returns the WPARAM of the last message dequeued and processed by
the MFC message loop. Unless you override this function and return what you
want, it's fairly random. For example, a dialog-based MFC app that doesn't
override ExitInstance() tends to return 13, which corresponds to the user
pressing Enter to exit the dialog. (13 is the keycode for Enter.) Other
types of MFC apps should return whatever value was passed to
PostQuitMessage(), which tends to be zero, because MFC calls this function
for you when you close the main window. To return the value you want
consistently, override ExitInstance, e.g.
int MyApp::ExitInstance()
{
CWinApp::ExitInstance();
return myCode;
}
--
Doug Harrison
Visual C++ MVP
Joseph M. Newcomer
program you're running doesn't do the right thing anyway. This is one of the reasons I
try to never run scripts, because you cannot tell what went wrong because the key programs
failed to return the right codes. This was one of my constant problems through 15 years
of Unix, where *everything* was done by scripts, and only a few of the programs actually
did the right thing with respect to return codes. I've found that GUI programs generally
never return a meaningful error code; since it is unpredictable and unreliable, it cannot
be depended on.
joe
David Ching
> That's why it rarely has any value. Most times, no one cares, and when
> you do care, the
> program you're running doesn't do the right thing anyway. This is one of
> the reasons I
> try to never run scripts, because you cannot tell what went wrong because
> the key programs
> failed to return the right codes. This was one of my constant problems
> through 15 years
> of Unix, where *everything* was done by scripts, and only a few of the
> programs actually
> did the right thing with respect to return codes. I've found that GUI
> programs generally
> never return a meaningful error code; since it is unpredictable and
> unreliable, it cannot
> be depended on.
Bad logic. If A is true, then B is true does not mean that if A is false,
then B is false.
A = All programs return valid codes
B = Return codes are useful
To say that return codes are not useful because few programs return valid
ones does not excuse us developers from developing programs that do return
valid codes (because then at least scripts that use our programs at least
will run correctly).
-- David
Joseph M. Newcomer
presence of code that doesn't let you do the specification easily is difficult to achieve.
I define the problem out of existence by saying if the return code mattered, it would
always be easy to return the right code trivially, and since there are not good mechanisms
built in, and no other program follows it, there's no reason for any program to expect the
return code has meaning. As far as I know, only a limited set of console-style programs
actually do this, and nearly all of them are compilers or compiler-like programs, not GUI
programs.
Normally, we do not have access to PostQuitMessage, and by default ExitInstance doesn't
even exist, so we take whatever happens by default. Even if ExitInstance exists, getting
it to return the right value is a bit tricky, since you have to put the value somewhere to
be returned; this requires creating a place to put it and a protocol for setting it.
Solving a problem that doesn't need to be solved isn't a good investment of time. It is
not clear why a GUI program needs an exit code, or why anyone should care (after all, the
notion of "exit code" is unique only to Unix shell programs, and almost no operating
system I know of in history *except* Unix ever used a mechanism like this. So imposing a
requirement that Windows programs work like Unix command shell scripts seems a bit odd.
So it only depends on whether or not you think a process *should* return a meaningful
code. Given that nearly none of them do, creating such a requirement on GUI programs is
of questionable value (saying "a program can return a value" is not the same as writing a
spec that requires EVERY program do so. In fact, I've looked through several documents I
have here on "proper Windows application design" and I cannot find any specification about
return codes being required. Unfortunately, all the links to online documents appear to
be broken (as in "page not found"), but I've never seen any official requirement that a
GUI program return any known or specific competion code upon completion. From what I
*have* found, apparently this is not any requirement for application logo certification.
So if the official position is that the return code does not matter, should I expend any
energy making it conform to a nonexistent specification?
joe
David Ching
Probably not, and only a handful of my GUI programs do return valid codes.
It depends on the usage of the programs. If the program's function is to
show a MessageBox with OK/Cancel and return true if OK is pressed, then
obviously there is a reason to return a valid code.
If there is a reason to return an error code, overriding ExitInstance() is a
simple matter of using the Properties window to add the virtual function.
Once there, just return the desired value, as Doug said. As for other parts
of the app storing the return value, AfxGetApp() provides an easy way of
getting the app. So I don't agree that returning a valid code is hard.
In summary, I agree that GUI apps rarely need to return valid error codes,
but disagree with your original reason that it is justified due to the fact
that error codes are in such bad shape that it is OK to add to the trend.
-- David
Joseph M. Newcomer
CWinApp level to clean up (almost never), I've not really had much need to add it.
No, I didn't suggest it is OK to add to a trend that is bad; what I said was that since
there is rarely any need for error codes, and historically they have never been
meaningful, spending effort conforming to an unspecified standard doesn't seem to be
productive. So from my viewpoint, there is not a "bad trend" merely an "irrelevant
feature". The lack of any spec from Microsoft that even suggests this is important or
meaningful means there is no actual "bad trend"; a "bad trend" would be a gratuitously
non-conforming program.
joe
David Ching
> I've occasionally had to add an ExitInstance, but since I rarely have
> anything at the
> CWinApp level to clean up (almost never), I've not really had much need to
> add it.
>
> No, I didn't suggest it is OK to add to a trend that is bad; what I said
> was that since
> there is rarely any need for error codes, and historically they have never
> been
> meaningful, spending effort conforming to an unspecified standard doesn't
> seem to be
> productive. So from my viewpoint, there is not a "bad trend" merely an
> "irrelevant
> feature". The lack of any spec from Microsoft that even suggests this is
> important or
> meaningful means there is no actual "bad trend"; a "bad trend" would be a
> gratuitously
> non-conforming program.
Well, I don't agree that a standard needs to be set for programs to return
valid error codes. As long as the program clearly defines what return code
is to be expected, anything is acceptable. Having been burned by careless
return values from programs that should have returned them, this is what I
advocate. For example, a GUI installer app should return some sort of valid
error code saying at bare minimum whether the installation was successful.
This is because the installer is launched from a Welcome application that
needs to show different things depending if the install was successful or
not.
-- David
Joseph M. Newcomer
should be part of the spec (as far as I can tell, all "standards" documents I've been able
to find, that didn't have broken links, mostly dealt with installer program conformance).
If the installer program standard is to return a meaningful error code, then failure to do
so is non-conforming. But if there is no standard, failure to adhere to an unspecified
requirement is not a failure of the program. But an installer program is a special case
of a GUI program, and a requirement for an installer program would not generalize to other
types of programs.
As such, it would be useful to raise this issue with Microsoft, and require a spec for a
conforming installer program that requires specific return codes, or classes of return
codes.
joe
David Ching
> The problem is that if a GUI installer app should return a code indicating
> success, this
> should be part of the spec (as far as I can tell, all "standards"
> documents I've been able
> to find, that didn't have broken links, mostly dealt with installer
> program conformance).
> If the installer program standard is to return a meaningful error code,
> then failure to do
> so is non-conforming. But if there is no standard, failure to adhere to
> an unspecified
> requirement is not a failure of the program. But an installer program is
> a special case
> of a GUI program, and a requirement for an installer program would not
> generalize to other
> types of programs.
>
What? How can there be a standard of error codes for all programs? I mean,
an Installer could have failure codes defined for INTERNET_NOT_AVAILABLE,
INSUFFICICENT_DISK_SPACE, etc. whereas the program that displays the
messagebox and returns 1 if OK is pressed and 0 if CANCEL is pressed has
very different codes.
And even if you decided to make a standard assigning DWORD's for all
possible error codes, why would this be useful? The only thing consuming
the error code is the thing that launched the app. And that thing knows
which app is launched. So it can easily adjust its processing of return
codes according to those defined by the app itself, and no standard is
needed.
-- David
Tom Serface
I agree with you, but I find that people seldom pay any attention to error
codes from a GUI. I don't think there is any standard either except for
perhaps returning 0 if it exited normally. I tend to pop up errors from my
GUI or write them to a log file. I have a log file writer that I use that
the user can enable, and I always log critical errors caused by exceptions.
GUI installers are a different animal. Someone might call one installer
from another and really need to figure out if the called program worked or
not.
I DO use ExitInstance() to do things like disconnect from servers and clean
up items that were collected or opened for the life of the program. I don't
do anything major there, but I find it a handy paradigm.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:oyFsj.10088$Ch6....@newssvr11.news.prodigy.net...
David Ching
news:B9765D48-435F-4C8B...@microsoft.com...
> Hi David,
>
> I agree with you, but I find that people seldom pay any attention to error
> codes from a GUI. I don't think there is any standard either except for
> perhaps returning 0 if it exited normally. I tend to pop up errors from
> my GUI or write them to a log file. I have a log file writer that I use
> that the user can enable, and I always log critical errors caused by
> exceptions.
>
> GUI installers are a different animal. Someone might call one installer
> from another and really need to figure out if the called program worked or
> not.
>
> I DO use ExitInstance() to do things like disconnect from servers and
> clean up items that were collected or opened for the life of the program.
> I don't do anything major there, but I find it a handy paradigm.
>
Most GUI apps are interactive, so the return value is unimportant, since
already you are losing the history of the user's actions, and the final
result is not even clear what that is. But there are cases where the
purpose of running the GUI is known from the outset, and the return value
should definitely indicate the result of that purpose. I don't think there
needs to be a "standard" to force the issue, and I can't imagine just what
that standard would be if there was one; I just think it should be by
convention and a best practice.
-- David
Tom Serface
returning "to" or "from" so it's less likely that people will use return
codes and, instead, use some sort of interprocess communication scheme. Of
course, you can wait for objects that you ShellExecuteEx(), but I even find
that to be klunky.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:UlJsj.7078$5K1...@newssvr12.news.prodigy.net...
David Ching
> Agreed, however with Windows it is often difficult to know what you are
> returning "to" or "from" so it's less likely that people will use return
> codes and, instead, use some sort of interprocess communication scheme.
> Of course, you can wait for objects that you ShellExecuteEx(), but I even
> find that to be klunky.
>
But your GUI app could just as well be invoked from a batch file... which of
course halts until the program returns. This is pretty common, actually.
-- David
Tom Serface
that.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:IuKsj.7089$5K1...@newssvr12.news.prodigy.net...
Joseph M. Newcomer
As such, it would be useful to raise this issue with Microsoft, and require a spec for a
conforming installer program that requires specific return codes, or classes of return
codes.
"Classes of standards" could mean "0 for success, nonzero for error. If the user-defined
bit (bit 29) of the return code is 1, then the installer shall provide [description of
what this means, here] a MESSAGETABLE resource against which that error code can be
interpreted".
That's one way to specify what is going on, which *could* be universal.
Then note that if two programmers agree on an exit code protocol of their choice, there is
no problem, so the issue you were complaining about, that installers-in-general do not
return meaningful error codes, goes away. The creator of the installer program chooses to
do something and the creator of the program launching the installer program agrees to use
that specification. If there is no agreement, there is no reason to expect an arbitrary
program will have to return a code consistent with some other arbitrary program, and
consequently you are back at the point where the issue of error codes being meaningless is
again true.
joe
Joseph M. Newcomer
Seriously, one of the great things about using Windows is that I rarely write batch files,
and the only case I still use sets up an environment variable for the awk compiler I have
so the awk runtime can be found (AWKPATH=), and invoking the awk compiler with the long
list of switches and options required. In a reasonable world, this information would be
specified once. Some day I'm going to write a little program that does this for me
automatically, and remembers the settings in the Registry for each project (not this week,
though; after browsing email and newsgroups, it's Tax Prep Time Again...)
One of the things I universally detested about Unix and Unix philosophy was that you could
use scripts to do everything. Scripts and pipes were the answer to every problem. There
was a time when I could tell you about the quoting conventions in three kinds of Unix
shells that were required to make the scripts run at all, and the disaster was that if a
script returned nonzero, all you knew was "something failed" but you had no idea which of
the many steps *actually* failed, and consequently what state the data ended up in. Half
of my scripting code was trying to figure out how to return appropriate error notification
to the caller of the script, and clean up whatever mess the failure left behind.
There was a time in my life when I was really interested in scripting languages of all
sorts, and had even written a few. With Windows, I no longer have to care at all about
them, and I like it that way.
joe
David Ching
Well, installers weren't the only types of programs I was complaining about,
but if you want a standard, I see no harm (and no benefit) in it. As I
said, the program launching the installer knows what installer it is
launching, so the important thing is that the installer return meaningful
error codes that can be deciphered by the launcher program, whether those
meaningful error codes conform to a spec or not.
-- David
David Ching
> Duh, what's a "batch file"?
>
However, IT people use them all the time.
-- David