How to debug Windows graphics in Microsoft
I’ve been in MS for more than two years now, and still in the debugger I spend most of my useful time (more only in Outlook).
I used to do the Windows Imaging Component , a new library for working with images, and now DXGI is a hardware acceleration infrastructure. The first is entirely in user mode, the second in both kernel and user, but the overall experience of debag is basically the same.
Whoever finds the bug and wherever it crashes - always send a remote, that is, remote debugging. And almost always - immediately, without reminders. After the report about the beautiful immediately connect and see - the most natural action.
There are symbols servers to take out symbols for main builds. From the source control to take the necessary versions of sors by build number.
If you did not react for several days and the machine was idle in more beautiful - then full memory dump.
On the instrumented build, again, if you ask, they will try to repeat it. In this sense, automatic testing also helps a lot - it becomes much easier to repeat. Surprisingly, this is required very rarely, most likely because they can debug without.
')
Remote, of course, for Jedi debuggers. Forget visual studio. Debaggers in Windows (in any case, in unmanaged-part) two - cdb and windbg, one another kosher.
cdb is a pure console debugger. g, bp, register reads, memory and stack dumps, line number and sourse file name as a means of viewing sorts.
windbg - on top of this can a little from the usual ordinary mortals. It shows the code, it shows the breakpoints in red, there are even watch and call stack windows. Watch works disgusting, update on mood, does not understand complex expressions, and so on. Why is that? Because it does not need all this real Jedi. The most valuable part of the windbg is the console, anyway, the whole thing is there.
And while they are very powerful. They put all possible brekpoynty - to download dll, to load the driver, to access anywhere. They will get into the unload DLL, they may pop up characters, they will show the version of exe and so on. To learn all the features, I think you need a few years of intensive training. And, yes, another fun thing is collective debugging, when there are several people in one debug console.
People can debug at a very low level, they start looking at the asm code and the bare stack-trace without blinking an eye. My former lead always carries with itself a magic piece of paper on which it is drawn where and how when a function is called, the functions are put on the ip and esp stack, which goes to ebp, where local variables are put. Magic artifact, +2 to debugging skills. And it was necessary more than once and not two. Previously, I would just send a nafig, send a debagging build and tell me to do repro with him, or I would sit down for a week with a change of code, a thousand printf and a million restarts, but it turns out that they can debug it without.
To illustrate - tell a favorite story.
Fell away and in the release build of Vista, gave the remote, I want to see the variable functions in the middle of the stack. Until this debugger can not unwind. It is clear why - this was in ecx, because call is internal, it was pushed onto the stack when the next function was called, it is somewhere in the middle of the stack frame and the debugger cannot find it at all.
Lead launches his favorite cdb, pulls out an artifact piece of paper, starts looking at a stack dump. There are a lot of pointers nearby, it just doesn't look that way. He says - it will be more serious, we will look at the asm-code in the place of the call, let's see how he pushed this on the stack. It is necessary to print dizasm functions.
Dials a console command that prints a code with line tags by function name. It prints for some reason only half, apparently a limit on the number of output. Tormented with the parameters does not help.
He says irritably "Forget these fancy new commands, lets do it old-fashioned way." Takes the address of the code of this function, which one looks in the sourse file of the next one, takes its address, dumps a bare dizasm between them. Finds in it pushy and the necessary call, happy ending.
That is, a team that automatically, by the name of the function, dysasms with its lines is a newfangled crap, or a dump between two addresses.
What then is VS debugger?
And while - I did not see in Windows bugs, which are beyond debugging. It happens that you sit for several days, it happens that the help of men from the other team is needed, it happens that the bug bounces many times (or is collectively debugged), but nevertheless, if it falls regularly (even not necessarily a constant repro), find it.
1) To be able to do from everywhere and always remote debug. Have a base of characters for all builds.
2) Do not be afraid of low level.
3) Invest in this environment.
And for all these reasons - when something falls or slows down at home in Windows, seditious thoughts begin to come to symbols.
And debug.
I used to do the Windows Imaging Component , a new library for working with images, and now DXGI is a hardware acceleration infrastructure. The first is entirely in user mode, the second in both kernel and user, but the overall experience of debag is basically the same.
Whoever finds the bug and wherever it crashes - always send a remote, that is, remote debugging. And almost always - immediately, without reminders. After the report about the beautiful immediately connect and see - the most natural action.
There are symbols servers to take out symbols for main builds. From the source control to take the necessary versions of sors by build number.
If you did not react for several days and the machine was idle in more beautiful - then full memory dump.
On the instrumented build, again, if you ask, they will try to repeat it. In this sense, automatic testing also helps a lot - it becomes much easier to repeat. Surprisingly, this is required very rarely, most likely because they can debug without.
')
Remote, of course, for Jedi debuggers. Forget visual studio. Debaggers in Windows (in any case, in unmanaged-part) two - cdb and windbg, one another kosher.
cdb is a pure console debugger. g, bp, register reads, memory and stack dumps, line number and sourse file name as a means of viewing sorts.
windbg - on top of this can a little from the usual ordinary mortals. It shows the code, it shows the breakpoints in red, there are even watch and call stack windows. Watch works disgusting, update on mood, does not understand complex expressions, and so on. Why is that? Because it does not need all this real Jedi. The most valuable part of the windbg is the console, anyway, the whole thing is there.
And while they are very powerful. They put all possible brekpoynty - to download dll, to load the driver, to access anywhere. They will get into the unload DLL, they may pop up characters, they will show the version of exe and so on. To learn all the features, I think you need a few years of intensive training. And, yes, another fun thing is collective debugging, when there are several people in one debug console.
People can debug at a very low level, they start looking at the asm code and the bare stack-trace without blinking an eye. My former lead always carries with itself a magic piece of paper on which it is drawn where and how when a function is called, the functions are put on the ip and esp stack, which goes to ebp, where local variables are put. Magic artifact, +2 to debugging skills. And it was necessary more than once and not two. Previously, I would just send a nafig, send a debagging build and tell me to do repro with him, or I would sit down for a week with a change of code, a thousand printf and a million restarts, but it turns out that they can debug it without.
To illustrate - tell a favorite story.
Fell away and in the release build of Vista, gave the remote, I want to see the variable functions in the middle of the stack. Until this debugger can not unwind. It is clear why - this was in ecx, because call is internal, it was pushed onto the stack when the next function was called, it is somewhere in the middle of the stack frame and the debugger cannot find it at all.
Lead launches his favorite cdb, pulls out an artifact piece of paper, starts looking at a stack dump. There are a lot of pointers nearby, it just doesn't look that way. He says - it will be more serious, we will look at the asm-code in the place of the call, let's see how he pushed this on the stack. It is necessary to print dizasm functions.
Dials a console command that prints a code with line tags by function name. It prints for some reason only half, apparently a limit on the number of output. Tormented with the parameters does not help.
He says irritably "Forget these fancy new commands, lets do it old-fashioned way." Takes the address of the code of this function, which one looks in the sourse file of the next one, takes its address, dumps a bare dizasm between them. Finds in it pushy and the necessary call, happy ending.
That is, a team that automatically, by the name of the function, dysasms with its lines is a newfangled crap, or a dump between two addresses.
What then is VS debugger?
And while - I did not see in Windows bugs, which are beyond debugging. It happens that you sit for several days, it happens that the help of men from the other team is needed, it happens that the bug bounces many times (or is collectively debugged), but nevertheless, if it falls regularly (even not necessarily a constant repro), find it.
Short recap:
1) To be able to do from everywhere and always remote debug. Have a base of characters for all builds.
2) Do not be afraid of low level.
3) Invest in this environment.
And for all these reasons - when something falls or slows down at home in Windows, seditious thoughts begin to come to symbols.
And debug.
Source: https://habr.com/ru/post/43179/
All Articles