Help: Win32 error 16r0?

I have a deployed application which one customer says is generating a
win32 error (16r0: The operation completed successfully) when one of
the UI buttons is pressed (the code, in turn, executes a DOS batch
script).
Doing some digging around on this group, I noticed reference to a
similar error in the development environment when clicking on
inherited methods in the class browser. But, this was fixed with patch
level 1....
So...anyone have clues on what's going on here? I haven't been able to
reproduce the error yet on our machines. We're still on patch level 1
-- could that be the source of difficulty (although this is the first
time the problem has surfaced....)

As usual, any and all help greatly appreciated!

Thanks,

KeithB

More details on the 16r0 error:
customer running Windows 98 SE
128 MB of ram

Here's the error log from the problem:
New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack <----*
[071506DC: 422]-->50
[071506D8: 421]-->60
[071506D4: 420]-->nil
[071506D0: 419]-->' (16r0: The operation completed successfully.)'
[071506CC: 418]-->a VMLibrary
[071506C8: 417]-->59409242
[071506C4: 416]-->RuntimeSessionManager>>logError:
[071506C0: 415]-->59409254
[071506BC: 414]-->8
[071506B8: 413]-->59409230
[071506B4: 412]-->a Win32Error
[071506B0: 411]-->a KnowledgeWorksSessionManager
[071506AC: 410]-->59409228
[071506A8: 409]-->SessionManager>>unhandledException:
[071506A4: 408]-->59409238
[071506A0: 407]-->7
[0715069C: 406]-->59409216
[07150698: 405]-->a Win32Error
[07150694: 404]-->a KnowledgeWorksSessionManager
[07150690: 403]-->59409214
[0715068C: 402]-->SessionManager>>onUnhandledError:
[07150688: 401]-->59409224
[07150684: 400]-->3
[07150680: 399]-->59409202
[0715067C: 398]-->a Win32Error
[07150678: 397]-->a KnowledgeWorksSessionManager
[07150674: 396]-->59409202
[07150670: 395]-->Error>>defaultAction
[0715066C: 394]-->59409210
[07150668: 393]-->8
...
<361 slots omitted>
...
[071500C0: 31]-->a MethodContext
[071500BC: 30]-->BlockClosure>>ifCurtailed:
[071500B8: 29]-->59408484
[071500B4: 28]-->20
[071500B0: 27]-->59408462
[071500AC: 26]-->59408458
[071500A8: 25]-->BlockClosure>>ensure:
[071500A4: 24]-->59408470
[071500A0: 23]-->7
[0715009C: 22]-->59408446
[07150098: 21]-->nil
[07150094: 20]-->[] @ 34 in ExceptionHandlerAbstract>>try:
[07150090: 19]-->[] @ 15 in ExceptionHandlerAbstract>>try:
[0715008C: 18]-->a MethodContext
[07150088: 17]-->ExceptionHandlerAbstract>>try:
[07150084: 16]-->59408454
[07150080: 15]-->42
[0715007C: 14]-->59408436
[07150078: 13]-->59408432
[07150074: 12]-->BlockClosure>>on:do:
[07150070: 11]-->59408444
[0715006C: 10]-->10
[07150068: 9]-->59408420
[07150064: 8]-->[] @ 12 in BlockClosure>>newProcess
[07150060: 7]-->ProcessTermination
[0715005C: 6]-->[] @ 8 in InputState>>forkMain
[07150058: 5]-->[] @ 6 in BlockClosure>>newProcess
[07150054: 4]-->BlockClosure>>newProcess
[07150050: 3]-->59408428
[0715004C: 2]-->20
[07150048: 1]-->0
<Bottom of stack>

Thanks,

KeithB
*----> Stack Back Trace <----*
{071506B8: cf 0715069D, sp 071506CC, bp 071506B4, ip 5,
KnowledgeWorksSessionManager(RuntimeSessionManager)>>logError:}
{0715069C: cf 07150681, sp 071506AC, bp 07150698, ip 4,
KnowledgeWorksSessionManager(SessionManager)>>unhandledException:}
{07150680: cf 07150665, sp 07150690, bp 0715067C, ip 4,
KnowledgeWorksSessionManager(SessionManager)>>onUnhandledError:}
{07150664: cf 0715064D, sp 07150674, bp 07150664, ip 5,
Win32Error(Error)>>defaultAction}
{0715064C: cf 07150639, sp 0715065C, bp 0714C710, ip 57,
Win32Error(Exception)>>_propagateFrom:}
{07150638: cf 0715061D, sp 07150648, bp 07150634, ip 6,
Win32Error(Exception)>>_propagate}
{0715061C: cf 07150605, sp 0715062C, bp 0715061C, ip 12,
Win32Error(Exception)>>signal}
{07150604: cf 071505ED, sp 07150614, bp 07150604, ip 4, Win32Error
class(Exception class)>>signal}
{071505EC: cf 071505D5, sp 071505FC, bp 071505EC, ip 3,
UserLibrary(ExternalLibrary)>>systemError}
{071505D4: cf 071505BD, sp 071505E4, bp 0714C780, ip 109,
MessageBox>>basicOpen}
{071505BC: cf 071505A5, sp 071505D0, bp 071505BC, ip 4,
MessageBox>>open}
{071505A4: cf 07150589, sp 071505B4, bp 071505A0, ip 10,
MessageBox>>errorMsg:}
{07150588: cf 07150569, sp 07150598, bp 07150580, ip 9, MessageBox
class>>errorMsg:caption:}
{07150568: cf 07150555, sp 07150578, bp 07145A20, ip 137, [] in
AmPalmOSFlexBuilder>>build}
{07150554: cf 07150539, sp 07150564, bp 071458D0, ip 33, [] in
MessageNotUnderstood(Exception)>>_evaluateHandler:in:}
{07150538: cf 07150525, sp 07150550, bp 0714C2E8, ip 17,
BlockClosure>>ifCurtailed:}
{07150524: cf 07150505, sp 07150534, bp 0715051C, ip 4,
BlockClosure>>ensure:}
{07150504: cf 071504F1, sp 07150514, bp 071458D0, ip 49,
MessageNotUnderstood(Exception)>>_evaluateHandler:in:}
{071504F0: cf 071504DD, sp 07150500, bp 0714C7F0, ip 44,
MessageNotUnderstood(Exception)>>_propagateFrom:}
{071504DC: cf 071504C1, sp 071504EC, bp 071504D8, ip 6,
MessageNotUnderstood(Exception)>>_propagate}
{071504C0: cf 071504A9, sp 071504D0, bp 071504C0, ip 12,
MessageNotUnderstood(Exception)>>signal}
{071504A8: cf 07150489, sp 071504B8, bp 071504A0, ip 13,
MessageNotUnderstood class>>receiver:message:}
{07150488: cf 0715046D, sp 07150498, bp 07150484, ip 5,
AmPalmOSFlexBuilder(Object)>>doesNotUnderstand:}
{0715046C: cf 07150459, sp 0715047C, bp 07137600, ip 299,
AmPalmOSFlexBuilder>>makePdbWith:}
{07150458: cf 07150445, sp 07150468, bp 07145A20, ip 120, [] in
AmPalmOSFlexBuilder>>build}
{07150444: cf 07150431, sp 07150454, bp 0714C898, ip 11,
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}
[hidden email] (ksbag) wrote in message news:<[hidden email]>...

Keith,

In addition to your lead re pl1, this looks like it could be Win9x nonsense.
I'm basing that mostly on experience with similar kinds of problems, and
worse, that all disappeared when I was finally able to ditch win9x for 2k.
Prior to that, I was able to greatly reduce the problems by reducing
finalizable garbage (especially GDI objects), so you might want to look at
that possibility.  Ideally, you should not have to worry about it, but the
problem is that Windows (especially 9x) will get into trouble if starved for
resources.

Please note that I'm not telling you to just tell your customer to upgrade
and all will be well.  They might be unwilling, or even uable to change to a
new OS.  However, it is possible that the machine is being clobbered by its
workload.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]