Activating debugger in case of crash in program compiled from the command line

[James Kanze]

I'm currently porting a fairly large batch of code from Unix
(Solaris, Linux) to Windows, compiling from the command line.
One of the test programs crashes, causing the error Window to
pop-up. (I presume that this is like a core dump under Unix.)
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?

FWIW: the command line used to compile the files is:

cl -c -Foc:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testScanner.obj -Fdc:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testScanner.pdb -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -
DNOMINMAX -DGB_EFmtDoesntWork -D_CRT_SECURE_NO_DEPRECATE -GS- -Zi -w -
D_DEBUG_ -Ic:/kanze/generated/tmp/testAscii.tst6128 -DIS_UTF8=false -
I. -I./conf/i80x86-win32-vc80 -Ic:/kanze/generated/include -Ic:/kanze/
generated/include/conf/i80x86-win32-vc80 -Tp testScanner.cc

(all on one line). The same for all of the other source files,
then:

cl -Fmc:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testScanner -Fd -Fec:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testScanner.exe -vmg -GR -Gy -EHs -Zc:forScope,wchar_t -J -nologo -
DNOMINMAX -DGB_EFmtDoesntWork -D_CRT_SECURE_NO_DEPRECATE -GS- -Zi -w -
D_DEBUG_ -Ic:/kanze/generated/tmp/testAscii.tst6128 -DIS_UTF8=false -
I. -I./conf/i80x86-win32-vc80 -Ic:/kanze/generated/include -Ic:/kanze/
generated/include/conf/i80x86-win32-vc80 c:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testErrorHandler.obj c:/kanze/generated/tmp/testAscii.tst6128/
component/CodeGeneratorExecs/scangen/testScanner.obj c:/kanze/
generated/tmp/testAscii.tst6128/component/CodeGeneratorExecs/scangen/
testToken.obj c:/kanze/generated/tmp/testAscii.tst6128/component/
CodeGeneratorExecs/scangen/testTokenMap.obj c:/kanze/generated/tmp/
testAscii.tst6128/component/CodeGeneratorExecs/scangen/ScannerBase.obj
c:/kanze/generated/lib/GabiProgMgt.lib c:/kanze/generated/lib/
GabiText.lib c:/kanze/generated/lib/GabiIO.lib c:/kanze/generated/lib/
GabiUtil.lib c:/kanze/generated/lib/GabiTest.lib c:/kanze/generated/
lib/GabiBase.lib

While there's probable some undefined behavior in my code which
causes this, unless I can get a stack walkback, and see exactly
where it's crashing, I can't start looking for it.

I'm running Window XP Family edition, with Service Pack 3
installed; the version of C++ is Visual Studios Visual C++ 2008
Express Edition.

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[j***@cix.compulink.co.uk]

In article

Post by James Kanze
One of the test programs crashes, causing the error Window to
pop-up. (I presume that this is like a core dump under Unix.)

Not very much like it at all, really. It has in common with a core dump
that it's a default action when a program crashes in particular ways,
but that's about all.

You need to give up on assuming that things happen in the same way as
Solaris or Linux now; they are very different, and you're going to have
to go through a bit of a learning curve.

Post by James Kanze
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?

Is the error window telling you anything about what the crash is? You
usually do get offered the debugger still these days: were you using an
Express Edition of Visual Studio when it worked?

A simple method of debugging such a problem is to start the Visual
Studio IDE, open the .EXE file, and select Debug=>Start debugging from
the menu. Note that by default the debugger will not catch most hardware
traps; you need to enable them with Debug=>Exceptions.

[James Kanze]

Post by j***@cix.compulink.co.uk
In article

Post by James Kanze
One of the test programs crashes, causing the error Window
to pop-up. (I presume that this is like a core dump under
Unix.)

Not very much like it at all, really. It has in common with a
core dump that it's a default action when a program crashes in
particular ways, but that's about all.

Well, that's more or less what I meant. That my program had
done something bad, like trying to access unmapped memory.

Post by j***@cix.compulink.co.uk
You need to give up on assuming that things happen in the same
way as Solaris or Linux now; they are very different, and
you're going to have to go through a bit of a learning curve.

I'm aware that it's very different. I've installed a Unix-like
toolkit to attenuate the differences, but even then.

Post by j***@cix.compulink.co.uk

Post by James Kanze
In earlier versions of the system, the Window offered me the
option to enter the debugger (assuming Visual Studios C++ was
installed, which is the case); this one doesn't. So how can I
see where I'm crashing, and a trace of the stack?

Is the error window telling you anything about what the crash
is?

No. It was just offered the choice between aborting and sending
a message to Microsoft.

Post by j***@cix.compulink.co.uk
were you using an Express Edition of Visual Studio when it
worked?

I have the Express Edition installed, but the GUI certainly
wasn't active.

Post by j***@cix.compulink.co.uk
A simple method of debugging such a problem is to start the
Visual Studio IDE, open the .EXE file, and select Debug=>Start
debugging from the menu. Note that by default the debugger
will not catch most hardware traps; you need to enable them
with Debug=>Exceptions.

Well, I finally got into the debugger by creating a dummy
project in a temporary directory, then specifying the path to
the executable (and to the sources). I'd tried opening the
.exe, but IIRC, I got an error message to the effect that there
was no editor capable of handling that sort of file.

--
James Kanze (GABI Software) email:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]