Compile it with -ggdb3 and try again. Looks like you crashed your graphic driver bad.

How i use ggdb3? ggdb3 and gdb3 don't works - must i install anything else?

backtrace? you mean that i write instead "run" - "backtrace" or what?
If i do this, i get this message: "No Stack."

I have changed my Makefile to this:

But if i compile now (with aware error) and start then gdb with "gdb map.exe" this error comes:

edit:
if i write "n" by this and the next question, gdb starts. If i write now "run" the same error comes:

Is it too big to post the full code to test it? I would suggest you to comment functions until it doesn't crash, it is probably memory corruption.

Yes I agree but for a good debugging experience your choices seem to be:
1. msvc on windows
2. gdb on linux/osx

You could try to install a VM with ubuntu in it and debug in that in the future.

You could try the intel debugger (idb). Intel's compiler is like 99% backwards compatible with g++ so you don't have to change anything to get it to work.

You can download the intel compiler for free for non-commercial use, just google around for it.

I was asking myself the same thing...

It doesn't work too well. GDB is designed to work with signals (eg. SIGABRT, SIGSEGV), but Windows likes to use exceptions. This causes GDB to not catch signals reliably, and sometimes crash GDB itself instead of the app.

gdb also seems to have quite some trouble with the windows threading model.

MSVC creates the projects for you, and you can simply add everything inside a folder to your project. It's not THAT complicated. It used to be quite bad and counter-intuitive, but the 2008 version is actually pretty good. And even though MSVC creates a project file for you, it doesn't touch your source files unless you tell it to.
If you are used to coding with a text editor and a command line, switching to an IDE does take some getting used to, I admit that.
My point is, MSVC is "the" compiler for windows, just like gcc is the compiler for gnu/linux. If you want to do serious windows development, be prepared to use MSVC, at least for some parts of your development process.

For the die-hards, there is always "manual debugging". It works as follows:
- Write very clean and readable code, with truckloads of concise, to-the-point comments; make sure the code is modular and maintainable, document everything unambiguously (especially function behaviour, return values and arguments); be consistent in everything you do including indentation and naming conventions; refactor early, optimize late (or not at all); favour readability over speed.
- Use assert() all over the place. When something goes wrong, chances are one of the asserts will catch it and tell you where things are not what you want them to be. If no assert() catches the error at hand, add more asserts to find it.
- When assert doesn't give you what you need, use trace() to dump line numbers and the values of interesting variables into a trace file. This is the manual equivalent of setting a breakpoint and examining variables. The technique can also be used to trace the program flow after the fact; place trace() statements at strategic locations (e.g. the beginning and end of each function, right before and after any decision, etc.); when stuff goes wrong, open up the trace file and see what the last actions of your program were.
- If you want to make absolutely sure that a certain line of code is reached, put in an assert that always fails (assert(0)). If the line is reached, the assert must fire.
- In the case of a graphical application, you can use the console to dump debugging information