Invalid access to memory location. Reading 0x1000AEB0, IP 0x1000AEB0

I just got a bug report from a user with a problem I once had on my dev
machine but have since been unable to reproduce or understand.

The start of the ERROR dump is:

16:53:05 PM, 10/02/2004: Invalid access to memory location. Reading
0x1000AEB0, IP 0x1000AEB0 (C:\Program Files\Bulletin
TXTMail\SMSComposer.exe)

And the stack takes a GPFault from
ProcessorScheduler->UserLibrary->InputState and never touches any of my
own code, unfortunately the only thing I know about the user in
questions machine is the comment "I loaded it up on WinXP 2002 SP2".

This is from a ToGo application from Dolphin 5.1.4.

Unfortunately I don't have any more information than this ( other than
the .ERRORS file which doesn't really reveal anything to me ) which
isn't very helpfull to me, or anyone reading this.  If it was happening
on all installations I would begin to think maybe something was wrong
with the image or the ToGo application, but it works fine on all
machines I've tried it on, anyone have any ideas?


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

16:53:05 PM, 10/02/2004: Invalid access to memory location. Reading
0x1000AEB0, IP 0x1000AEB0 (C:\Program Files\Bulletin
TXTMail\SMSComposer.exe)

*----> VM Context <----*
Process: {07A30004:size 170 words, suspended frame 07A301E1, priority 5,
callbacks 0
last failure 2:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 06C2DA0D (13)
SP: 07A30358
BP: 07A30330 (187)
ActiveFrame: {07A30334: cf 07A30319, sp 07A30348, bp 07A30330, ip 5,
TXTMailSessionManager(SessionManager)>>logError:}
    receiver: a TXTMailSessionManager
    arg[0]: a GPFault


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

*----> Stack Back Trace <----*
{07A30334: cf 07A30319, sp 07A30348, bp 07A30330, ip 5,
TXTMailSessionManager(SessionManager)>>logError:}
    receiver: a TXTMailSessionManager
    arg[0]: a GPFault

{07A30318: cf 07A302FD, sp 07A30328, bp 07A30314, ip 4,
TXTMailSessionManager(SessionManager)>>unhandledException:}
    receiver: a TXTMailSessionManager
    arg[0]: a GPFault

{07A302FC: cf 07A302E1, sp 07A3030C, bp 07A302F8, ip 4,
TXTMailSessionManager(SessionManager)>>onUnhandledError:}
    receiver: a TXTMailSessionManager
    arg[0]: a GPFault

{07A302E0: cf 07A302C9, sp 07A302F0, bp 07A302E0, ip 5,
GPFault(Error)>>defaultAction}
    receiver: a GPFault

{07A302C8: cf 07A302B5, sp 07A302D8, bp 06E7FF28, 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('Main' base 07A30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)
    temp[4]: nil

{07A302B4: cf 07A30299, sp 07A302C4, bp 07A302B0, ip 6,
GPFault(Exception)>>_propagate}
    receiver: a GPFault
    temp[0]: nil

{07A30298: cf 07A30281, sp 07A302A8, bp 07A30298, ip 12,
GPFault(Exception)>>signal}
    receiver: a GPFault

{07A30280: cf 07A30261, sp 07A30290, bp 07A30278, ip 8, GPFault
class(Win32Fault class)>>signal:with:}
    receiver: GPFault
    arg[0]: nil
    arg[1]: a EXCEPTION_RECORD

{07A30260: cf 07A30245, sp 07A30270, bp 07A3025C, ip 5, GPFault
class(Exception class)>>signalWith:}
    receiver: GPFault
    arg[0]: a EXCEPTION_RECORD

{07A30244: cf 07A30225, sp 07A30254, bp 07A3023C, ip 11,
ProcessorScheduler>>gpFault:}
    receiver: a ProcessorScheduler
    arg[0]: a ByteArray
    temp[0]: a EXCEPTION_RECORD

{07A30224: cf 07A30209, sp 07A30234, bp 06E7FEB8, ip 11, [] in
ProcessorScheduler>>vmi:list:no:with:}
    receiver: a ProcessorScheduler
    arg[0]: 476
    arg[1]: nil
    arg[2]: 5
    arg[3]: a ByteArray

{07A30208: cf 07A301F5, sp 07A30220, bp 06E7FEF0, ip 17,
BlockClosure>>ifCurtailed:}
    receiver: [] @ 5701638 in nil
    arg[0]: [] @ 16 in ProcessorScheduler>>vmi:list:no:with:
    temp[0]: nil
    temp[1]: nil
    temp[2]: nil

{07A301F4: cf 07A301E1, sp 07A30204, bp 06E7FEB8, ip 20,
ProcessorScheduler>>vmi:list:no:with:}
    receiver: a ProcessorScheduler
    arg[0]: 476
    arg[1]: nil
    arg[2]: 5
    arg[3]: a ByteArray

{07A301E0: cf 07A301AD, sp 07A301F0, bp 07A301C4, 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

{07A301AC: cf 07A3018D, sp 07A301BC, bp 07A301A4, ip 3,
UserLibrary>>enumWindows:lParam:}
    receiver: a UserLibrary
    arg[0]: a ByteArray
    arg[1]: 0

{07A3018C: cf 07A30179, sp 07A3019C, bp 06E7FE80, 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

{07A30178: cf 07A30165, sp 07A30188, bp 06E7FE48, ip 23, InputState>>uiIdle}
    receiver: a InputState
    temp[0]: nil

{07A30164: cf 07A3014D, sp 07A30174, bp 07A30164, ip 3,
InputState>>aboutToIdle}
    receiver: a InputState

{07A3014C: cf 07A30131, sp 07A3015C, bp 07A30148, ip 5,
InputState>>waitForInput:}
    receiver: a InputState
    arg[0]: true

{07A30130: cf 07A30109, sp 07A30140, bp 07A30120, ip 34,
InputState>>loopWhile:}
    receiver: a InputState
    arg[0]: [] @ 6 in InputState>>mainLoop
    temp[0]: a MSG
    temp[1]: true
    temp[2]: nil

{07A30108: cf 07A300F5, sp 07A30118, bp 06E7FDA0, ip 12,
InputState>>mainLoop}
    receiver: a InputState

{07A300F4: cf 07A300E1, sp 07A30104, bp 06E7F9B0, ip 13, [] in
InputState>>forkMain}
    receiver: a InputState

{07A300E0: cf 07A300CD, sp 07A300F0, bp 06E7FD68, ip 11,
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}
    receiver: a ExceptionHandler
    temp[0]: nil

{07A300CC: cf 07A300B1, sp 07A300DC, bp 06E7FB00, 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('Main' base 07A30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07A300B0: cf 07A3009D, sp 07A300C8, bp 06E7FC50, ip 17,
BlockClosure>>ifCurtailed:}
    receiver: [] @ 5701638 in nil
    arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
    temp[0]: nil
    temp[1]: nil
    temp[2]: nil

{07A3009C: cf 07A3007D, sp 07A300AC, bp 07A30094, ip 4,
BlockClosure>>ensure:}
    receiver: [] @ 15 in ExceptionHandlerAbstract>>try:
    arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
    temp[0]: nil

{07A3007C: cf 07A30069, sp 07A3008C, bp 06E7FB00, ip 39,
ExceptionHandler(ExceptionHandlerAbstract)>>try:}
    receiver: a ExceptionHandler
    arg[0]: [] @ 8 in InputState>>forkMain
    temp[0]: nil
    temp[1]: nil
    temp[2]: a Process('Main' base 07A30000 [ACTIVE] in
SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07A30068: cf 07A30049, sp 07A30078, bp 07A30060, ip 7,
BlockClosure>>on:do:}
    receiver: [] @ 8 in InputState>>forkMain
    arg[0]: ProcessTermination
    arg[1]: [] @ 12 in BlockClosure>>newProcess

{07A30048: cf 00000001, sp 07A30058, bp 06E7FC18, ip 17, [] in
BlockClosure>>newProcess}
    receiver: [] @ 8 in InputState>>forkMain
    temp[0]: nil

<Bottom of stack>

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

Mark,

> I just got a bug report from a user with a problem I once had on my dev
> machine but have since been unable to reproduce or understand.

Did your problem occur with the same exe, or one from an earlier
deployment?


Is that "the" SP2 (the one that has broken a lot of stuff)?  Are you
using the same OS?  Is the user in question using any debugging tools
(things that hook libraries, etc.)?


> This is from a ToGo application from Dolphin 5.1.4.
>
> Unfortunately I don't have any more information than this ( other than
> the .ERRORS file which doesn't really reveal anything to me ) which
> isn't very helpfull to me, or anyone reading this.

It looks like EnumWindows() is conking out.  Does it do this immediately
after the exe starts, or is more random?  My first thought (by no means
necessarily correct) is that you had a zombie view lurking in your image
at the time of deployment.

WAAAAAYYYYYYY out there: Do you use any DLLs or ActiveX controls?  If
you get substantial functionality from DLLs, do you overlap any calls?
There could be a thread affinity that strikes only under some circumstances.


 > If it was happening
> on all installations I would begin to think maybe something was wrong
> with the image or the ToGo application, but it works fine on all
> machines I've tried it on, anyone have any ideas?

It depends on the nature of the problem and why a particular machine
exposes it.  This might be a misconfigured box (bad drivers, bad
hardware, mangled by incomplete updates, etc.), or it might be one
machine that is being kind enough (though it might not seem that way at
the moment) to not mask a bug for you.

Have a good one,

Bill

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

Bill Schwab wrote:

> Did your problem occur with the same exe, or one from an earlier
> deployment?
>
Same executable.  I believe I found the problem, the exectutable
includes a package generated for the Microsoft Outlook COM objects,
under Outlook 2002 SP1 ( where the system hangs ) it seems MS "forgot"
to include an object/method which was later exposed in SP2 and greater (
when the system works ).

Just added a version check in my  Session Manager for this broken
version to pop up a dialog asking the user to upgrade, but this
unfortunately still throws the error as the objects still don't match up.

I see one of two options here:

1) change my installer to check the version of outlook and don't
install/warn the user.
2) dynamically load the outlook package on startup once I've worked out
its safe to do so, and enable that functionality

I havn't yet looked at binary packages but could see they could also be
a good way of allowing me to download updated versions of my app over
the net.  I see I need to apply for a DolphinSure certificate in order
to use this.

For now I'll just settle for 1, but I'd like to do 2 if it works.

Mark,

> Same executable.  I believe I found the problem, the exectutable
> includes a package generated for the Microsoft Outlook COM objects,
> under Outlook 2002 SP1 ( where the system hangs ) it seems MS "forgot"
> to include an object/method which was later exposed in SP2 and greater (
> when the system works ).

It might not be MS' fault.  Since your generated package includes the
offending interface, it sounds as though you generated from an SP2 type
library.

This is one reason that I prefer to approach such things as in my Word
Automation package.  It is more work to start, but it's  more likely to
work across versions.  I suspect it would also give you the "dynamic
loading" that you want by allowing you to "feel your way" more than
appears to be possible with a generated package - that is just a guess,
but it seems reasonable based on how IDispatch works.

Regular readers of this group will know my stock advice: when practical,
code it yourself.  If you use Outlook to do simple things like sending
email, then using alternate methods would be a nice gesture for your
users, as it would avoid exposing them to (based on the track record)
significant vulnerabilities.

Another way to look at (disagree if you wish) is that FireFox could
(some would say should) put quite a strain on MS' market share.  IMHO,
it might be in your interest to be ready for a shift away from IE and
friends.  In your favor, it sounds as though you are reasonably
independent of Outlook even now.


> Just added a version check in my  Session Manager for this broken
> version to pop up a dialog asking the user to upgrade, but this
> unfortunately still throws the error as the objects still don't match up.

Perhaps you could use the IDispatch (see my Word Automation package for
what I mean) approach just long enough to check the version??  That
might not fix your problem, but it might at least allow a graceful exit.

Have a good one,

Bill


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