views:

70

answers:

5

I've got a project that I need to get working with 3 compilers (borland, gnu, and microsoft). It works on 2/3 and now I just need to get it working with microsofts. It seems to crash in places that it works fine with the other compilers, so I'm wondering if there is a way to debug with the command line, maybe to get a stack trace or get the line which caused the crash, something similar to gdb with gnu.

Didn't manage to find any answers with google, so if anyone has any ideas, I will love you.

+1  A: 

Yes.

C++ : Building on the Command Line

C# : See Debug-Centric Options of csc.exe.

Leniel Macaferi
A: 

Codeview is an older product which does that, but there's no reason why you couldn't use visual studio to do the same thing.

wallyk
+2  A: 

Debugging Tools for Windows - an outstanding package of debugging tools that includes the cdb and ntsd console debugger (in addition to the GUI WinDBG debugger).

The package has fantastic docs, can easily be set up to be the 'just in time' debuggers that handle a crash, and works very very nicely with crash dumps.

These are the hardcore debugging tools that Microsoft uses for crash analysis (and more).

Note that Windows comes with a version of ntsd debugger (at least it used to - looks like it's not on my Win7 box outside of the tools package installation), but it's a great idea to get the package anyway so you have the latest tools - and like I said the docs are a wealth of great information.

Michael Burr
Downloading this package as a type.
Marcin
+6  A: 

(Full disclosure: I work on the Visual Studio team)

If you're using the Microsoft C++ compiler, do you have Visual Studio installed already? If so, you can use the built-in debugger. If not, I would recommend trying Visual C++ 2010 Express for free. It has an excellent native debugger. You can break on first chance exceptions (C++, SEH, Win32 exceptions) and go right to the line where it happened along with the call stack, locals, etc.

Chris Schmich
I tried using the attach process functionality, but that only showed me the line on what looked like assembly code of my application.
Marcin
@Marcin - you'll need to make sure that you have symbols for you application and you should also configure Visual Studio's debugger to use the Microsoft public symbol server so you can get good stack traces if the crash happens in a Windows API.
Michael Burr
+1 - it's been a long time since I had a command-line program I couldn't debug in the Visual Studio IDE. Going back to the days of Borland C++ 5, there were frequent cases where you'd get different behaviour because of different memory layouts. That may be possible still in VC++, but the kinds of pointer issues that cause the issue have got a lot rarer with better coding practices - and in any case, there are IIRC tools to help with that too. I recently had a pointer alias optimisation bug in gcc (my bug - gcc doing what it's meant to) - gdb worked, but it was *very* painful to use.
Steve314
Thanks Michael, that seemed to help me! I enabled the public symbol server and I can basically step through my code.
Marcin
+1  A: 

Well, you are having trouble with the one compiler that tries very hard to crash your program on purpose. It's called "Run-time error checks", the /RTC option compile option. You can turn it off to make it behave like those other ones. Or you could pursue the "something's wrong here" angle. It's well documented in the MSDN Library article for /RTC.

Hans Passant