Making Debug run faster.

[xoft]

If you need something defined first, put it in the stdafx.h (or whatever file you use for precompiled headers). Or in the project settings. That way you can keep precompiled headers.

LeakFinder was a great find, I still can't believe such a useful code lies on the net for free
Setting it up is really easy - add the two cpp files to the project, #include the LeakFinder.h in your main cpp and call the Init and Deinit functions at program start / end. That's it.

---

Leakfinder is extremely useful - it lists all the leaked memory together with stacktrace where it was allocated, and still it's fast - i have no idea how they do that

[ThuGie]

Hey,

I added leakfinder and am running it now.
Its all fine really really slow but thats fine the server keep crashing loads of times :p.
Different places each time though but still ok.

As it reveals different kinds of problems but atm still unable to narrow down where it go's wrong any more tips on how to increase the chance i find the location where it actually go's wrong ?

Should i look somewhere else then the Call Stack window ?

[xoft]

Are you using MS Application Verifier? That's a really useful thing, too. It can enable loads of debugging features built into Windows, one of them being guard pages around heap allocations. It might help you pinpoint the issues in your app.

Otherwise there's not much that can be said in general, most of the times you'll be hunting a specific issue and there is no generic recipe for that.

You should be using the stack window, the watches, memory window etc. Also with App verifier, it outputs its debugging info into the Output window, that comes in handy as well. When judging multithreaded code, remember to ask yourself, upon each line, "is there any way this could be accessed by another thread simultaneously? Will it cause problems if another thread modified this under my hands?" Forgetting to lock things using critical sections is one of the most common source of heap problems in multithreaded programs.

[xoft]

App Verifier is a free standalone package from MS, but they bundle it with most of their dev software. I think it comes with Platform SDK as well as the Debugging Tools. Still, it's available as a standalone download if you want to be sure you have the latest version.

App verifier is only useful in combination with a debugger, because it triggers a breakpoint whenever it feels you're doing something wrong (such as freeing memory with an undeleted critical section in it); you need to be running under a debugger to catch that.

---

Settings: keep the default for the start. You'll see how many problems you hit.

You still need to add your exe to the list of applications for the verified to work on it.

[ThuGie]

Yeah i know i tried it once.
But local i didn't encounter error more like i never encounter errors local..

So i have to run it on the live server for it to actually trow a error same for the leakfinder.
Local no error live server yeah it does trow them every 5 minutes :p.

Edit:
Well i tried it out on the server and there indeed crashes.
But.. it doesn't give me any info about where it happend..
The only info it gives me is asm or about source files that the app verifier itself seems to use and thus i dont have..
a file sdk.ccp and more in a c:\ directory i dont have :p so.. kinda useless for me .

[xoft]

You need to run the program under a debugger in order to be able to catch the verifier output.

Then when the verifier throws an exception, use the debugger to view stack trace. Of course the first few items will be from verifier (it had to throw the exception somehow), but then it'll be your app's code doing the mischief.

[xoft]

Did you have the app's debugging symbols and sources on the server as well? The debugger can't display what it doesn't have
Maybe post a screenshot of the Stack window

[xoft]

Do you have VS configured to download symbol files from MS servers? You might need to, otherwise the stack can be mis-interpreted by VS, therefore not showing any of your code.