CODEWITHSUNDEEP
windowskerneldriverwindbgkernel-module
ben
ben

Reputation: 21

WinDbg shows some variables but not others, shows some variables in same location

I'm trying to use WinDbg 6.2.9200.16384 x64 over a serial cable to debug a driver I'm writing. WinDbg connects to the target machine (Windows 8) just fine, and I see all the dbgprints as the system boots and loads everything. I can load the symbols for my driver just fine and can set breakpoints, and when my driver hits those breakpoints, the system halts as expected. This is where things get weird: when I hit a breakpoint, I can only see some of the local variables in my function in both the locals window and when using the 'dv' command. I created a variable to test with:

int myInt = 8;

When I use a dbgprint to show the value of myInt, it works fine and I see it as 8. However, the variable doesn't even appear at all in the locals window or with the 'dv' command. Other variables do, such as

ULONG rcb = 0;

and I can see its value just fine in the locals window. These variables are literally declared one after the other.

Another symptom of this strange problem is this. I have a function

ULONG someFunction(UINT16 offset) {
   ULONG rcb, tempAddr, temp, temp1;
   ULONG writeAddr, readAddr;
   UINT16 dev;

   dev = 15;
   ...
}

I call this function like so:

someFunction(0x777);

When I set a breakpoint in this function and inspect the variable values with WinDbg, nothing makes any sense. First, it only sees 4 of my 8 variables, just offset, rcb, writeAddr, and readAddr. It tells me the value of offset is not 0x777 as I would expect, but 0xE061 (this changes each time I run the code). When I look closer at the locals window (same information is shown via 'dv' and '? varname' commands) I notice that the location of offset and the location of rcb are the exact same address. Likewise, writeAddr and readAddr are stored at the same address as well. None of the other variables are detected by the debugger.

I am convinced that I've loaded the symbols properly, the source and symbols paths are set correctly, I've run '.reload /f' a million times with no errors loading my driver's symbols. I'm still able to break and step through other lines of code, but the locals just don't make any sense. When I dbgprint, the correct values are shown so it seems like this is a problem with the debugger itself, not with my driver. Any ideas?

Upvotes: 1

Views: 1925

Answers (2)

ben
ben

Reputation: 21

I fixed the problem. To anyone else who runs into this same thing: I was working with a free build of the driver, so the compiler had optimized out a lot of my variables. To fix it, either compile a checked version of the driver, or add the line 

MSC_OPTIMIZATION=/Od /Oi

to your sources file to disable optimizations for the free build. Hope this helps anyone with the same problem.

Upvotes: 1

Rahul Sundar
Rahul Sundar

Reputation: 490

<> Nowadays Compiler has been enhanced a lot to get better optimized binary with optimized performance and other metrics. Hence compiler store few variables as locals(visible via 'dv /v' command) and store other variables in their registers. That's the reason you didn't see variable int myInt in dv command. We can get to know which registers are being used for the variables, by disassembling the function using 'uf binary!functionname' or by viewing disassembled code in Windbg View-> Disassembly.

Note that the driver may behave little differently with and without optimization of the compiler in the aspects of performance, memory usage, etc. So its always recommended to debug the one generated from the default optimized compiler, as this is the one used in realtime user scenario.

Upvotes: 1

Related Questions