Debugging tools for windows
Previously, I did not know what a subject was and did not know how to use it. Now learned a little and impressed. I'll tell you about my experience with him, maybe someone will be useful.
These tools contain powerful debuggers (WinDbg, Cdb) and allow you to do all sorts of usefulness, such as creating symservers (symstore.exe), creating a dump from the process (cdb, windbg), debugging memorials (umdh.exe) and other memory errors ( gflags - allows you to include many "hidden" system checks for a specific exe file, and for the whole system). Also included are many other useful tools, such as the debug output viewer.
You can take it here: microsite
')
For example, how to get memorials for any program:
We will need umdh.exe, tlist.exe and gflags.exe. All of them must be run with admin rights.
Run gflags.exe, tick the Create user mode stack database. Reboot - now this database will be created for all running programs. You can configure for each application separately.
Next, run the desired program, wait until everything is loaded and get the PID of the program using tlist.exe (or whatever else). For example, PID == 111.
Next, run umdh.exe -p: 111 -f: c: \ temp \ log1.log
This line will save to the log1.log file information about all current memory allocations in the process 111.
Then we work in the program, wait for some time and write again:
umdh.exe -p: 111 -f: c: \ temp \ log2.log
We get the second log with allocations of memory.
Now you can compare them and get the faces:
umdh.exe -d -v -lc: \ temp \ log1.log c: \ temp \ log2.log 1> c: \ temp \ log_result.log
Now in log_result.log we will have all allocated and not freed chunks of memory with calsteks!
In order for kalsteks to be correct, you need to set the enviroment variable _NT_SYMBOL_PATH. In the help it is written how to configure it for Microsoft exe and dll.
It’s best to save your pdb to the symbol server, which can be replenished after the builds with the help of symstore.exe - then the debugger will always have the correct pdb.
If there is no server, you can simply put the pdb next to the exe - it should pick up. If not picked up, then add the path to the pdb in _NT_SYMBOL_PATH.
If you have a dump file and you need to check it, then again the easiest way is to use WinDbg. It uses the same _NT_SYMBOL_PATH variable and, unlike VisualStudio, it does not require the source code or the correct binary for debugging. Just a dump and a suitable pdb! Run WinDbg.exe, File \ open crash dump ..., open the dump, write! Analyze -v, then! Uniqstack, and this is usually enough in simple cases. You can see which pdbs were found, which ones aren’t and get the dump analysis. You can open windows with callstack, Processes and threads and debug. If you need to see the code - File \ Source File Path ... - specify the path to the source code and you can look at the place in the code where what happened (it’s better to register these paths in the enviroment variable _NT_SOURCE_PATH immediately, so as not to drive them in each time). In short, again, everything is simple and convenient, if there is a correct pdb :)
Problems with freezing something are perfectly solved by dumping a hung process. To do this, you can use the same WinDbg or special programs or a standard system feature in whist in Task Manager - create a dump :)
Moreover, DebuggingTools can be installed after a hang - no reboot is needed. Installed - took a dump. To remove the dump, the user does not need any pdb.
Then you analyze and correct this dump (in Windbg there are special commands for searching deadlocks, etc. - the command! Locks and others).
Conclusion:
In order not to have problems with debugging, you need to take care of the storage system for pdb files for EVERY build, or at least for official builds. And also study Debugging tools and write simple recommendations to testers and programmers - what to do in case of an error or a hang, how to create a dump, where to put it and with which comments. And some testers can even run WinDBG and copy-paste to the bug report from there the necessary data like a kalstek with an error - it helps a lot in preliminary analysis.
In addition, a couple of useful links for beginners about WinDBG:
WinDbg. From A to Z!
Common WinDbg Commands (Thematically Grouped)
These tools contain powerful debuggers (WinDbg, Cdb) and allow you to do all sorts of usefulness, such as creating symservers (symstore.exe), creating a dump from the process (cdb, windbg), debugging memorials (umdh.exe) and other memory errors ( gflags - allows you to include many "hidden" system checks for a specific exe file, and for the whole system). Also included are many other useful tools, such as the debug output viewer.
You can take it here: microsite
')
For example, how to get memorials for any program:
We will need umdh.exe, tlist.exe and gflags.exe. All of them must be run with admin rights.
Run gflags.exe, tick the Create user mode stack database. Reboot - now this database will be created for all running programs. You can configure for each application separately.
Next, run the desired program, wait until everything is loaded and get the PID of the program using tlist.exe (or whatever else). For example, PID == 111.
Next, run umdh.exe -p: 111 -f: c: \ temp \ log1.log
This line will save to the log1.log file information about all current memory allocations in the process 111.
Then we work in the program, wait for some time and write again:
umdh.exe -p: 111 -f: c: \ temp \ log2.log
We get the second log with allocations of memory.
Now you can compare them and get the faces:
umdh.exe -d -v -lc: \ temp \ log1.log c: \ temp \ log2.log 1> c: \ temp \ log_result.log
Now in log_result.log we will have all allocated and not freed chunks of memory with calsteks!
In order for kalsteks to be correct, you need to set the enviroment variable _NT_SYMBOL_PATH. In the help it is written how to configure it for Microsoft exe and dll.
It’s best to save your pdb to the symbol server, which can be replenished after the builds with the help of symstore.exe - then the debugger will always have the correct pdb.
If there is no server, you can simply put the pdb next to the exe - it should pick up. If not picked up, then add the path to the pdb in _NT_SYMBOL_PATH.
If you have a dump file and you need to check it, then again the easiest way is to use WinDbg. It uses the same _NT_SYMBOL_PATH variable and, unlike VisualStudio, it does not require the source code or the correct binary for debugging. Just a dump and a suitable pdb! Run WinDbg.exe, File \ open crash dump ..., open the dump, write! Analyze -v, then! Uniqstack, and this is usually enough in simple cases. You can see which pdbs were found, which ones aren’t and get the dump analysis. You can open windows with callstack, Processes and threads and debug. If you need to see the code - File \ Source File Path ... - specify the path to the source code and you can look at the place in the code where what happened (it’s better to register these paths in the enviroment variable _NT_SOURCE_PATH immediately, so as not to drive them in each time). In short, again, everything is simple and convenient, if there is a correct pdb :)
Problems with freezing something are perfectly solved by dumping a hung process. To do this, you can use the same WinDbg or special programs or a standard system feature in whist in Task Manager - create a dump :)
Moreover, DebuggingTools can be installed after a hang - no reboot is needed. Installed - took a dump. To remove the dump, the user does not need any pdb.
Then you analyze and correct this dump (in Windbg there are special commands for searching deadlocks, etc. - the command! Locks and others).
Conclusion:
In order not to have problems with debugging, you need to take care of the storage system for pdb files for EVERY build, or at least for official builds. And also study Debugging tools and write simple recommendations to testers and programmers - what to do in case of an error or a hang, how to create a dump, where to put it and with which comments. And some testers can even run WinDBG and copy-paste to the bug report from there the necessary data like a kalstek with an error - it helps a lot in preliminary analysis.
In addition, a couple of useful links for beginners about WinDBG:
WinDbg. From A to Z!
Common WinDbg Commands (Thematically Grouped)
Source: https://habr.com/ru/post/30654/
All Articles