mfc, application crashes outside Visual Studio

hi,

i've developped an mfc application, which uses 2 external
dlls (Xerces and curl) and an activeX control to access the
local machine's WMI. the application does it's stuff in a
timer triggered loop, ie every 30 seconds or so it accesses
some info via WMI.

Everything works fine when I run the app inside VS.NET (in
both debug and release configs), but when i run the app
outside the IDE, it crashes after a few loops (4 or 5).

All this in windows xp sp1.

Can anyone help?
Thanks in advance
d

Which version fails? Debug or release?

If debug, it is real easy: just run the app outside vs, and when it crashes, select the
option to invoke the debugger (called Just-In-Time, or JIT, debugging). Then look at what
went wrong.

If it is only the release version that fails, first, read my essay on MVP Tips site,
"surviving the release version". If you are using user-defined messages, the most likely
cause is you didn't read the documentation and have the prototypes of your handlers
completely wrong (they MUST be LRESULT name(WPARAM, LPARAM), and nothing, repeat nothing,
else can possibly work). If that is not the cause, my essay tells how to create debug
symbols for the release version (and the problems that can follow), then simply follow the
same procedure for JIT debugging as with a debug version.
joe

On Fri, 14 Nov 2003 07:11:08 -0800, "diogodpc" < XXXX@XXXXX.COM >



Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

actually both versions fail. i've just detected a small
memory leak, and i'm hoping it's connected to that. I will
read your essay. thanks

diogo


and when it crashes, select the
JIT, debugging). Then look at what
my essay on MVP Tips site,
user-defined messages, the most likely
prototypes of your handlers
LPARAM), and nothing, repeat nothing,
essay tells how to create debug
follow), then simply follow the
< XXXX@XXXXX.COM >

hi again,

unfortunately, I've solved the memory leak and the app
still won't run for long outside the IDE, on either of the
configs...

when I JIT debug, I see that sometimes the crashe happens
on code that has worked on previous iterations, other times
"no source code is avaliable for the current location", or
on the xerces dll. I get a "Memory could not be read"
error. I have looked in to some dynamic condition that
would cause the error, but i can't get past the fact that
all the iterations are exactly alike (same information
retrieved over and over again) and the code works inside
VS.NET (both configs).

any other thoughts?

thanks

id you look at the backtrace to see where you made the call that led to the error?

Note that this could be the result of a memory damage bug, which are notoriously hard to
find.
joe

On Tue, 18 Nov 2003 04:24:42 -0800, "diogodpc" < XXXX@XXXXX.COM >
wrote:


Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

i,

the strange thing is the error happens on different zones
of the code. For example: one of the functions I have reads
some app info from the registry, and sometimes the error
occurs on the function caller, other within the function.
All this happens only on the second iteration of the
program. To my best knowledge, the registry related system
calls are made as seen on the msdn sample code. Right now
I'm getting an error on RegQueryValueEx, but that's not
always the case.

On a more general note, can you please point me to
somewhere where I can understand the difference between
running an app within VS (ie pressing F5) and running it
via double click on the .exe?

thanks a lot for everything,
diogo


call that led to the error?
which are notoriously hard to
< XXXX@XXXXX.COM >
access the
accesses

ot sure what might be happening. It is hard to guess without seeing more detail of the
code. It reeks of memory damage (which often has the property that the errors appear to be
random; one of the key rules of development is "if you ever see a memory damage bug, track
it down and kill it NOW!" because otherwise the bug still exists, it just damages
something that may hide the bug for a while (like until post-deployment).

The first place to consider is any malloc or new of an array of elements to make sure you
are allocating the right amount of information. Try to avoid raw allocation and use
CString, CArray, std::string, std::vector, and other high-level (and bounds-checked) array
types. Look for uninitialized pointer variables (write LPSOMETHING thing = NULL; instead
of LPSOMETHING thing;), use of pointers after you've done a free/delete of the object
pointed to, and things like that.

What you have is most likely one of the nastiest bugs you can have to track down. What
surprises me (and delights me) as that since I started using MFC I simply don't have these
errors. Those who have adopted STL have similar experiences. Those who do raw malloc or
free live on the edge. I once participated in a 3-day marathon debugging session (I'd call
up one of the other team members, and he'd take over from me, and I'd go to bed) because
there was an equivalent of malloc(n) when it should have been malloc(n+1). The damage
didn't show up until hundreds of millions of instructions later.

Running an app under F5 runs it under the debugger. Double-clicking it does not run under
the debugger. When run under the debugger, the working directory is set to the source
directory; running from double-click, the working directory is set to the working
directory of the shortcut that launches it, and if there is none set, it is some useless
entity like "My Documents".
joe

On Wed, 19 Nov 2003 08:35:54 -0800, "diogodpc" < XXXX@XXXXX.COM >
wrote:


Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

i joe,

I've fixed the thing! Not sure how, though...

Apparently this code doesn't work:

if (hrNext == WBEM_S_FALSE || uNumOfInstances == 0)
bFinished = true;
else
{

and this does:

if (hrNext == WBEM_S_FALSE)
bFinished = true;
else if (hrNext == WBEM_S_NO_ERROR)
{

uNumOfInstances gets initialized with spEnumInst 2 lines
before, so it's probably an unchecked return code. Views?

Anyway, it's been the first time I've heard about this
memory damage bugs. Can you point me to somewhere where I
can read something about them?

Thanks a lot for everything!
diogo


without seeing more detail of the
property that the errors appear to be
ever see a memory damage bug, track
exists, it just damages
post-deployment).
array of elements to make sure you
avoid raw allocation and use
high-level (and bounds-checked) array
LPSOMETHING thing = NULL; instead
a free/delete of the object
can have to track down. What
using MFC I simply don't have these
experiences. Those who do raw malloc or
marathon debugging session (I'd call
me, and I'd go to bed) because
been malloc(n+1). The damage
later.
Double-clicking it does not run under
directory is set to the source
directory is set to the working
is none set, it is some useless
< XXXX@XXXXX.COM >
that can
external
in a
VS.NET (in