jim@newmedia.UUCP (Jim Beveridge) (03/22/91)
Help!!! I am completely stumped by a problem that I have run into. I am developing two DLLs and an application. The application calls the first DLL, which then calls the second. All DLL's are explicitly linked at LINK time. Optimization is disabled. The first time I run the application, everything works just fine. If I try and run it again, the system hangs. The mouse still moves, but that's about it. Before the 2nd run, I can start an application like the heap walker without any trouble. The moment I launch the application the second time, kaboom. Even more bizarre is the fact that I can make sure that none of the functions in the DLL are called so that they will be loaded but not executed, and the program will still die with the same behavior. This leads me to believe the problem is in LibMain or the WEP, but these are the bare minimum functions (ie. They both just return 1). I am utterly baffled. The problem has been randomly appearing and disappearing over the past few weeks, depending on how optimization and debugging are set, but now the problem persists no matter how I set the options. It is even doing things like working fine if I use the debugging version of Windows and crashing under the normal version. If anyone has any ideas, or you need more information, please send me mail or give me a call. Thanks, Jim Beveridge ----------------------------------------------------------------- email: ..!uunet!know!newmedia.UUCP!jim phone: (508) 663-0666 -----------------------------------------------------------------
dsampson@x102a.harris-atd.com (sampson david 58163) (03/22/91)
Jim -- your email address bounces at my site so I'll post instead.
You don't say whether you're doing anything in your DLLs during
initialization, like GlobalAlloc, GlobalLock, GlobalUnlock calls, etc.
As a drop back and punt approach, try creating dummy DLLs for test
purposes that only contain the MS code for LibEntry and WEP, and link
that to your application. Purposly get rid of your DLLs for the time
being. If the problem re-occurs, the it's in your Non-DLL code. If
it goes away, try bringing in 1 dll at a time until you isolate down
to the problem module.
Whenever I hear about random behavior in any code (usually my own on a
day to day basis :)) I always suspect memory allocation that's messed
up, a pointer that's declared but doesn't have any space allocated to
it, or a pointer that points to an object that was created by a MS lib
call.
This last item is usually missed by people and can result in
some severe behavior problems. To see if you have this particular
problem, see if you have a pointer to an object in memory that's
created by MS. I ran into this in the GetProfileStrings function. If
you pass NULL as the second parameter, MS "creates" a list of the LHS
stuff in a section of your win.ini file. I had a pointer point to the
list that they created so that I could parse the data. Fine. That
worked and I got the data. But when I wanted to exit my function
where this was going on, I had to steer my pointer variable away from
the MS data before exiting my function or it would hang the system
(randomly). I fixed it by making the thing point to NULL before I
exited the function. Everything works fine now.
I'm not saying this is your particular problem. You have some fault
isolation to do yet. But be aware that where a chrash occurs may not
be DIRECTLY correlated to where the problem actually resides (ain't
pointers wonderful????)
--
A new world record
in the javalin throw
/ /
/ I
-------------------------------------------------
David Sampson Harris Corporation
dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison
uunet!x102a!dsampson Melbourne, Florida
-------------------------------------------------------------------------------