WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.


Process ID

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

tGetLastError versus WIL LastError() and DebugTrace Results

Keywords:  debugtrace tGetLastError LastError()


The attached snippet from a DebugTrace shows a discrepancy between the error reported in the trace and the value obtained from tGetLastError. This is with the 2001 compiler and the latest Proc extender. I'm not trying to be anal about it but it would be nice if the numbers agreed. In my application I'm using tGetPriority to determine when a process has exited. After many tests I've discovered that a 201 (Open Process Failed) means one thing and a 237 (Unable to Get Priority) means something different. Sadly I'm now faced with redoing a bunch more tests hoping to discover the magic value tGetLastError returns on a 237 condition (which happens infrequently). My fear is that I'll run all those tests only to discover that the distinction is lost and tGetLastError returns 87 in both cases.
adeErrorHandler = IntControl(73,0,0,0,0)
(82134) VALUE=> "2"

adeEM = ErrorMode(@Off)
(82136) VALUE=> 1

adePriority = tGetPriority(autProcId)
(82138) VALUE=> 0

EXTENDER ERROR SUPPRESSED =>201 (201: Open Process Failed)

(82140) VALUE=> 0

(82142) VALUE=> "0"

if adePriority == 0
(82144) IF DO==>TRUE

xyz = tGetLastError()
(82145) VALUE=> 87

if xyz == 201


>The attached snippet from a
>DebugTrace shows a discrepancy
>between the error reported in
>the trace and the value
>obtained from tGetLastError.
tGetLastError is designed to retrieve EXTENDED process error information. Therefore inorder to retrieve the last extender error see the WIL function LastError().

I noticed you are using the ErrorMode and IntControl 73 error suppression options. You might want to chose just one, depending on your needs.

>This is with the 2001 compiler
>and the latest Proc extender.
>I'm not trying to be anal
>about it but it would be nice
>if the numbers agreed. 
They are designed for different uses. Please see the LastError function to capture the error 201.
>In my
>application I'm using
>tGetPriority to determine when
>a process has exited. After
>many tests I've discovered
>that a 201 (Open Process
>Failed) means one thing and a
>237 (Unable to Get Priority)
>means something different.
Yes, they do mean something different. Hence the different error messages.
>Sadly I'm now faced with
>redoing a bunch more tests
>hoping to discover the magic
>value tGetLastError returns on
>a 237 condition (which happens
>infrequently). My fear is
>that I'll run all those tests
>only to discover that the
>distinction is lost and
>tGetLastError returns 87 in
>both cases.
Here is an example on how to capture the last error and the Extended error.....
;This example is designed for NT

counter="bad string to force error"

ret=tGetdata(counter, typeflag)

if ret==0
  message("WIL Last error",WILerr)
  message("Extender Last error",Extendererr)

Message("tGetdata - value of %counter%",ret)
I will be happy to help you debug. PLease remove all error suppression for debugging, except for error that you truly want to ignore......

Question (cont'd):

You have solved my problem. I'll use LastError where I was using tGetLastError(). I humbly submit that my use of the latter was suggested by the the DebugTrace log. Compare the following two lines:
WIL ERROR SUPPRESSED =>1233 (RegQueryValue: Function Failed)  
EXTENDER ERROR SUPPRESSED =>237 (237: Unable to Get Priority.)
ErrorMode is off to let the WIL interpreter know that this is an anticipated error. IntControl 73 is off to avoid a jump to my error handler. (The code is just a tiny fragment of a large script where the error handler is useful.) FWIW this reminds me: it seems to me the WIL interpreter should not jump to the error handler anytime ErrorMode is off.


There was aproblem in some older version of WinBatch where the debugtrace function wasn't properly recognizing any Extender errors, but was writing out some other WIL error instead...

That has been fixed in the latest version. Sorry for the confusion. I agree that bug in DebugTrace, made it very misleading...

Article ID:   W14792
File Created: 2017:07:28:13:58:39
Last Updated: 2013:04:01:09:13:02