What is Proces.WaitCode = 255 ?

7 Sep 2006 8:41 AM

SMichal

Hi, I'm starting from my application simple bat data...test.bat.
This file (test.bat) should start another aplication app.exe.

I'm starting the test.bat from my application with Start() method of Process
class.
With proc.WaitForExit I'm waiting for end of the process and I must check
the
return code of process that I've started...this job does proc.ExitCode.

I'm alway dealing with returnCode = 255 but I'm pretty sure that the
application (which I've started) returns only this codes 0, 1 , 2, 3

So why do I get always the 255 retun code ?

7 Sep 2006 11:33 AM

Kevin Spencer

If it returns a signed byte, it is returning -1. A signed byte can have a
value between -127 and 127, with the most significant bit used as the sign
bit. So, 01111111 = 127. Add 1 to that, and you get 11111111, with the sign
bit being 1, which is negative. If it was unsigned, the value would indeed
be 255, but because the last bit is the sign bit, it is 1.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

Show quote

"SMichal" <michal.sodo***@trygon-softwareberatung.de> wrote in message
news:eNPeoll0GHA.772@TK2MSFTNGP05.phx.gbl...
> Hi, I'm starting from my application simple bat data...test.bat.
> This file (test.bat) should start another aplication app.exe.
>
> I'm starting the test.bat from my application with Start() method of
> Process
> class.
> With proc.WaitForExit I'm waiting for end of the process and I must check
> the
> return code of process that I've started...this job does proc.ExitCode.
>
> I'm alway dealing with returnCode = 255 but I'm pretty sure that the
> application (which I've started) returns only this codes 0, 1 , 2, 3
>
> So why do I get always the 255 retun code ?
>
>

7 Sep 2006 1:31 PM

Ben Voigt

"Kevin Spencer" <u**@ftc.gov> wrote in message
news:%23XlGmFn0GHA.1292@TK2MSFTNGP03.phx.gbl...
> If it returns a signed byte, it is returning -1. A signed byte can have a
> value between -127 and 127, with the most significant bit used as the sign
> bit. So, 01111111 = 127. Add 1 to that, and you get 11111111, with the
> sign bit being 1, which is negative. If it was unsigned, the value would
> indeed be 255, but because the last bit is the sign bit, it is 1.

Except that the exit code is a DWORD (=> UInt32 in CLR), not an sbyte. The
..NET team got it wrong when they made Process.ExitCode an int (although the
traditional unix C declaration for main returns int, Win32 process exit
codes are unsigned).

GetExitCodeProcess gives the following possibilities:
a.. The exit value specified in the ExitProcess or TerminateProcess
function.
b.. The return value from the main or WinMain function of the process.
c.. The exception value for an unhandled exception that caused the process
to terminate.

Warning If a process happens to return STILL_ACTIVE (259) as an error code,
applications that test for this value could end up in an infinite loop.

Is there a possibility that the process exited from a fatal exception? What
is cmd.exe's errorlevel after running the process?

Oh, and also 01111111b + 1 = 10000000b (unsigned: 128d, signed: -128d)

7 Sep 2006 4:20 PM

Kevin Spencer

Hi Ben,

Good points all. First things first!

> Oh, and also 01111111b + 1 = 10000000b (unsigned: 128d, signed: -128d)

Yes, I was thinking about adding a 1 at the end where the 0 was, but wasn't
clear about that!

> Except that the exit code is a DWORD (=> UInt32 in CLR), not an sbyte.
> The .NET team got it wrong when they made Process.ExitCode an int
> (although the traditional unix C declaration for main returns int, Win32
> process exit codes are unsigned).

Not necessarily. The WinMain function returns an int when called by the
WM_QUIT function. However, the data type is a signed 32-bit integer. I'm not
sure what exactly is being returned in this case, but it looks suspiciously
like it's an Int32. According to the .Net SDK, "You can use the exit code
much like an integer return value from a main() procedure." So, it is
probably getting the return value from the WinMain function.

However, that still doesn't tell us why the value is 255. The DWORD data
type is 32 bits, so it could possibly represent a negative integer, but
that's not relevant to this problem. Bottom line is, the value is 255. Now,
I looked at a number of Windows Header files, and couldn't find a definition
for this value, but there are quite a few of them.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

Show quote

"Ben Voigt" <rbv@nospam.nospam> wrote in message
news:O42f6Ho0GHA.1548@TK2MSFTNGP02.phx.gbl...
> "Kevin Spencer" <u**@ftc.gov> wrote in message
> news:%23XlGmFn0GHA.1292@TK2MSFTNGP03.phx.gbl...
>> If it returns a signed byte, it is returning -1. A signed byte can have a
>> value between -127 and 127, with the most significant bit used as the
>> sign bit. So, 01111111 = 127. Add 1 to that, and you get 11111111, with
>> the sign bit being 1, which is negative. If it was unsigned, the value
>> would indeed be 255, but because the last bit is the sign bit, it is 1.
>
> Except that the exit code is a DWORD (=> UInt32 in CLR), not an sbyte.
> The .NET team got it wrong when they made Process.ExitCode an int
> (although the traditional unix C declaration for main returns int, Win32
> process exit codes are unsigned).
>
> GetExitCodeProcess gives the following possibilities:
> a.. The exit value specified in the ExitProcess or TerminateProcess
> function.
> b.. The return value from the main or WinMain function of the process.
> c.. The exception value for an unhandled exception that caused the
> process to terminate.
>
> Warning If a process happens to return STILL_ACTIVE (259) as an error
> code, applications that test for this value could end up in an infinite
> loop.
>
> Is there a possibility that the process exited from a fatal exception?
> What is cmd.exe's errorlevel after running the process?
>
> Oh, and also 01111111b + 1 = 10000000b (unsigned: 128d, signed: -128d)
>
>