Dolphin 5.1.4 crashes under Windows 2003

The server is an HP ProLiant ML110G2, running Win2003 Standard Edition
SP1.
Dual Process or Pentium 4 3Ghz Family 15 Model 4 Stepping 1.

The problem occurs as soon as the application is started.
It run fine on Win2000 Server or Desktop PC running XP.

The dump points to a GPFault that looks like something to do with the
userlibrary but I'm not sure. Can anyone help?

Cheers, Theo Pronk

************************** Dolphin Virtual Machine Dump Report
***************************

12:02:06 PM, 11/28/2005: Invalid access to memory location. Writing
0x6DFCFDC, IP 0x6DFCFDC ()

*----> VM Context <----*
Process: {06F30004:size 170 words, suspended frame 06F301E1, priority
5, callbacks 0
last failure 2:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 06CED46D (13)
SP: 06F30358
BP: 06F30330 (187)
ActiveFrame: {06F30334: cf 06F30319, sp 06F30348, bp 06F30330, ip 5,
SASdownloadManagerSession(SessionManager)>>logError:}
        receiver: a SASdownloadManagerSession
        arg[0]: a GPFault


New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack Back Trace <----*
{06F30334: cf 06F30319, sp 06F30348, bp 06F30330, ip 5,
SASdownloadManagerSession(SessionManager)>>logError:}
        receiver: a SASdownloadManagerSession
        arg[0]: a GPFault

{06F30318: cf 06F302FD, sp 06F30328, bp 06F30314, ip 4,
SASdownloadManagerSession(SessionManager)>>unhandledException:}
        receiver: a SASdownloadManagerSession
        arg[0]: a GPFault

{06F302FC: cf 06F302E1, sp 06F3030C, bp 06F302F8, ip 4,
SASdownloadManagerSession(SessionManager)>>onUnhandledError:}
        receiver: a SASdownloadManagerSession
        arg[0]: a GPFault

{06F302E0: cf 06F302C9, sp 06F302F0, bp 06F302E0, ip 5,
GPFault(Error)>>defaultAction}
        receiver: a GPFault

{06F302C8: cf 06F302B5, sp 06F302D8, bp 06DFD630, ip 57,
GPFault(Exception)>>_propagateFrom:}
        receiver: a GPFault
        arg[0]: a ExceptionHandler
        temp[0]: nil
        temp[1]: a ExceptionHandler
        temp[2]: nil
        temp[3]: a Process(InputState>>forkMain base 06F30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)
        temp[4]: nil

{06F302B4: cf 06F30299, sp 06F302C4, bp 06F302B0, ip 6,
GPFault(Exception)>>_propagate}
        receiver: a GPFault
        temp[0]: nil

{06F30298: cf 06F30281, sp 06F302A8, bp 06F30298, ip 12,
GPFault(Exception)>>signal}
        receiver: a GPFault

{06F30280: cf 06F30261, sp 06F30290, bp 06F30278, ip 8, GPFault
class(Win32Fault class)>>signal:with:}
        receiver: GPFault
        arg[0]: nil
        arg[1]: a EXCEPTION_RECORD

{06F30260: cf 06F30245, sp 06F30270, bp 06F3025C, ip 5, GPFault
class(Exception class)>>signalWith:}
        receiver: GPFault
        arg[0]: a EXCEPTION_RECORD

{06F30244: cf 06F30225, sp 06F30254, bp 06F3023C, ip 11,
ProcessorScheduler>>gpFault:}
        receiver: a ProcessorScheduler
        arg[0]: a ByteArray
        temp[0]: a EXCEPTION_RECORD

{06F30224: cf 06F30209, sp 06F30234, bp 06DFD710, ip 11, [] in
ProcessorScheduler>>vmi:list:no:with:}
        receiver: a ProcessorScheduler
        arg[0]: 476
        arg[1]: nil
        arg[2]: 5
        arg[3]: a ByteArray

{06F30208: cf 06F301F5, sp 06F30220, bp 06DFD668, ip 17,
BlockClosure>>ifCurtailed:}
        receiver: [] @ 6094854 in nil
        arg[0]: [] @ 16 in ProcessorScheduler>>vmi:list:no:with:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{06F301F4: cf 06F301E1, sp 06F30204, bp 06DFD710, ip 20,
ProcessorScheduler>>vmi:list:no:with:}
        receiver: a ProcessorScheduler
        arg[0]: 476
        arg[1]: nil
        arg[2]: 5
        arg[3]: a ByteArray

{06F301E0: cf 06F301AD, sp 06F301F0, bp 06F301C4, ip 1,
UserLibrary(ExternalLibrary)>>invalidCall}
        receiver: a UserLibrary
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil
        temp[3]: nil
        temp[4]: nil
        temp[5]: nil
        temp[6]: nil

{06F301AC: cf 06F3018D, sp 06F301BC, bp 06F301A4, ip 3,
UserLibrary>>enumWindows:lParam:}
        receiver: a UserLibrary
        arg[0]: a ByteArray
        arg[1]: 0

{06F3018C: cf 06F30179, sp 06F3019C, bp 06DFD6A0, ip 21,
InputState>>topLevelHandlesDo:}
        receiver: a InputState
        arg[0]: [] @ 6 in InputState>>uiIdle
        temp[0]: a BlockCallback
        temp[1]: nil
        temp[2]: nil
        temp[3]: nil

{06F30178: cf 06F30165, sp 06F30188, bp 06DFD6D8, ip 23,
InputState>>uiIdle}
        receiver: a InputState
        temp[0]: nil

{06F30164: cf 06F3014D, sp 06F30174, bp 06F30164, ip 3,
InputState>>aboutToIdle}
        receiver: a InputState

{06F3014C: cf 06F30131, sp 06F3015C, bp 06F30148, ip 5,
InputState>>waitForInput:}
        receiver: a InputState
        arg[0]: true

{06F30130: cf 06F30109, sp 06F30140, bp 06F30120, ip 34,
InputState>>loopWhile:}
        receiver: a InputState
        arg[0]: [] @ 6 in InputState>>mainLoop
        temp[0]: a MSG
        temp[1]: true
        temp[2]: nil

{06F30108: cf 06F300F5, sp 06F30118, bp 06DFD860, ip 12,
InputState>>mainLoop}
        receiver: a InputState

{06F300F4: cf 06F300E1, sp 06F30104, bp 06DFDA58, ip 13, [] in
InputState>>forkMain}
        receiver: a InputState

{06F300E0: cf 06F300CD, sp 06F300F0, bp 06DFD7F0, ip 11,
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}
        receiver: a ExceptionHandler
        temp[0]: nil

{06F300CC: cf 06F300B1, sp 06F300DC, bp 06DFD978, ip 21, [] in
ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process(InputState>>forkMain base 06F30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{06F300B0: cf 06F3009D, sp 06F300C8, bp 06DFD908, ip 17,
BlockClosure>>ifCurtailed:}
        receiver: [] @ 6094854 in nil
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{06F3009C: cf 06F3007D, sp 06F300AC, bp 06F30094, ip 4,
BlockClosure>>ensure:}
        receiver: [] @ 15 in ExceptionHandlerAbstract>>try:
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil

{06F3007C: cf 06F30069, sp 06F3008C, bp 06DFD978, ip 39,
ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process(InputState>>forkMain base 06F30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{06F30068: cf 06F30049, sp 06F30078, bp 06F30060, ip 7,
BlockClosure>>on:do:}
        receiver: [] @ 8 in InputState>>forkMain
        arg[0]: ProcessTermination
        arg[1]: [] @ 12 in BlockClosure>>newProcess

{06F30048: cf 00000001, sp 06F30058, bp 06DFD9B0, ip 17, [] in
BlockClosure>>newProcess}
        receiver: [] @ 8 in InputState>>forkMain
        temp[0]: nil

<Bottom of stack>

***** End of dump *****

"Theo Pronk" <[hidden email]> wrote in message
news:[hidden email]...
I use (or at least used to use) Dolphin on Win2003 Enterprise Server all the
time on a dual proc box without encountering this issue, so I suspect it is
something to do with the machine config. A couple of things to check:

Is it a 4Gb server running with the /3Gb switch? (hmmm, probably not, only
supported on 2k3 Enterprise I think)
Is data execution protection enabled?

Regards

Blair

Blair McGlashan wrote:

> Is data execution protection enabled?

Would that have any effect on a Pentium box ?

Another thought: could there be a security policy setting to disable
EnumWIndows() on Win2003 ?  (I have no idea whether such a setting exists, nor
even where to look to find out, but there damn-well /should/ be one...)

BTW: why does InputState>>uiIdle not just iterate over the elements of the
'windows' map ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:438d7841$2$20534$[hidden email]...
> Blair McGlashan wrote:
>
>> Is data execution protection enabled?
>
> Would that have any effect on a Pentium box ?

It could if it is a recent one - the one's with x64 support it (or at least
the 64-bit Xeon machine I have does). I've no idea what all those numbers
mean, so I've no idea if the processor in question is recent, except that it
is 3Ghz, and therefore must be relatively recent.

>
> Another thought: could there be a security policy setting to disable
> EnumWIndows() on Win2003 ?  (I have no idea whether such a setting exists,
> nor
> even where to look to find out, but there damn-well /should/ be one...)

Don't necessarily see why, after all it enumerates only the windows in the
process, not those in other processes.

>
> BTW: why does InputState>>uiIdle not just iterate over the elements of the
> 'windows' map ?
>

To allow for windows not managed by Dolphin but still associated with the
process.

Regards

Blair

Blair,

> > > Is data execution protection enabled?
> >
> > Would that have any effect on a Pentium box ?
>
> It could if it is a recent one - the one's with x64 support it (or at
> least the 64-bit Xeon machine I have does).

Ah.  I hadn't realised Intel were catching up so fast ;-)


> > Another thought: could there be a security policy setting to disable
> > EnumWIndows() on Win2003 ?  (I have no idea whether such a setting
> > exists, nor
> > even where to look to find out, but there damn-well /should/ be one...)
>
> Don't necessarily see why, after all it enumerates only the windows in the
> process, not those in other processes.

It certainly enumerates windows belonging to other processes.  And I /think/ it
enumerates windows belonging to other users, but I may be wrong.  I was under
the impression that EnumWindows was a useful starting point for a Shatter
Attack. The MSDN entry for EnumWindows doesn't mention that restriction, and I
tried the following on my WinXP machine:

    pids := Set new.
    SessionManager current inputState topLevelHandlesDo:
        [:each || tid pid |
        pid := DWORD new.
        tid := UserLibrary default
                    getWindowThreadProcessId: each
                    lpdwProcessId: pid yourAddress.
        pids add: pid.
    true].

You'll need to add #getWindowThreadProcessId: unless you have it defined
already -- I've appended a defintion to the end of this.  For me, that loop
does find windows owned by other users, I'm not sure whether that's only
because I'm running with Admin priveledges, though.

(BTW, for anyone interested and doesn't already know about the Shatter
technique, see
    http://security.tombom.co.uk/shatter.html
for a starting point.)

Of course, even if EnumWindows does work how I think, the existance of a
security policy to turn it off is still pure speculation.


> > BTW: why does InputState>>uiIdle not just iterate over the elements of
> > the 'windows' map ?
> >
>
> To allow for windows not managed by Dolphin but still associated with the
> process.

Not sure what you mean by "managed by Dolphin".  If you mean windows that are
not serviced by Dolphin's input loop, then I don't understand why they should
expect to be sent #wmIdleUpdateCmdUI:xxx ?  I admit I don't really understand
the low-level architecture, though, especially where it's designed to cope with
non-MVP windows.  In any case, wouldn't replacing InputState>>uidle with a loop
based on the 'windows' map be a reasonable workaround for many people (if,
perhaps, ticklish to install) ?

    -- chris


=================
!UserLibrary methodsFor!

getWindowThreadProcessId: anExternalHandle lpdwProcessId: anExternalAddress
 "Retrieve the identifier of the thread that created the specified window and,
 optionally, the identifier of the process that created the window.
.

  DWORD GetWindowThreadProcessId(
   HWND hWnd,
   LPDWORD lpdwProcessId
  );"

 <stdcall: dword GetWindowThreadProcessId handle lpvoid>
#CUadded.
 ^self invalidCall
 ! !
!UserLibrary categoriesFor:
#getWindowThreadProcessId:lpdwProcessId:!public!win32 functions-process and
thread! !
=================

I wrote:

> [...] wouldn't
> replacing InputState>>uidle with a loop based on the 'windows' map be a
> reasonable workaround for many people

especially since (as I've only just noticed) #uiIdle: ignores window handles
from #topLevelHandlesDo: which don't have entries in the map...

    -- chris

> Is it a 4Gb server running with the /3Gb switch? (hmmm, probably not, only
> supported on 2k3 Enterprise I think)
> Is data execution protection enabled?

Finally was able to get access to the server, and yes DEP was enabled.
I put the ToGo.exe in the DEP exceptions list and it now works fine!!!

Thanks heaps for all your help.
Regards,
Theo

"Chris Uppal" <[hidden email]> wrote in message
news:438efaf1$0$20532$[hidden email]...
Hmmm, yes, you are right. In which case I am misremembering why this was
done.

It might have been because it was the only reliable way to identify all the
top-level windows that would not impose a particular protocol on windows
that might not be MVP. You may recall that MVP was not the only UI framework
we've had, and at some point I might have decided it was better to isolate
the very low level windowing code from the higher level framework and avoid
creating any dependencies that could be avoided. All the more so since I was
responsible for the low-level code, but not the frameworks. Since it was the
best part of 10 years ago, I can't really remember though.

At one point we could be hosted inside an MFC application. That message is
defined in MFC for the same purpose as it is used in Dolphin. At the time
(again, 10 years ago) windows apps were mainly MFC or VB, so it was
reasonable to assume that anything hosting Dolphin would likely be MFC.

>...I admit I don't really understand
> the low-level architecture, though, especially where it's designed to cope
> with
> non-MVP windows.  In any case, wouldn't replacing InputState>>uidle with a
> loop
> based on the 'windows' map be a reasonable workaround for many people (if,
> perhaps, ticklish to install) ?

Well it wouldn't work around this particular issue, because EnumWindows is a
red herring. It just happens to be the first use of a callback in the image.
Callbacks transit through machine code thunks that are dynamically generated
in heap allocated memory, hence the problem with data-execution-protection.

I'll certainly look at getting rid of that EnumWindows call in the future
though, if only to remove the overhead.

Regards

Blair

Blair,

I was bothered by this some time ago, squinted at it, and then concluded
that it must have been to allow for common dialogs, menus and/or other
stuff that is created strangely.  Does that sound right?

Have a good one,

Bill


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

Blair

> Callbacks transit through machine code thunks that are
> dynamically generated in heap allocated memory, hence the problem with
> data-execution-protection.

Is this something that you are planning to fix ?  It seems to me that Dolphin's
ExternalMemory allocators are flexible enough to create new thunks in memory
with PAGE_EXECUTE_READWRITE (or whatever) set.

OTOH, I can quite see the argument that since Dolphin programs are not written
in broken old 'C' they don't need to be protected against themselves (and
incompetent programmers) by such a clunky hack as DEP.  So it's the users'
responsibility to turn it off, not yours to waste yet more time coding around
Microsoft's whims...

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:43942205$1$20535$[hidden email]...
Yes (although not in 5.1), just haven't got round to it yet. Since it is
still relatively uncommon, and easily disabled on a per-app basis, we
haven't treated it as a particularly high priority.

Regards

Blair