Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
.frame supports the invocation where you specify an = followed by rbp, rsp, rip. Has anyone ever been able to get this to work in kernel mode? No matter what combination I provide, I always get a "range error". Here is my situation:
Crash occurs in an assembly routine. Looking at the dump, the saved trap only understands the current frame (the asm routine). kb prints the asm routine name and then just raw numbers for the rest of the stack. This asm routine subtracts off a large chunk of stack to store various registers. Since I know what that amount is (0x118) I can do something like
kb = @rsp+118
and I see the full stack decoded properly. Next, I would like to jump to other frames in this stack and view their locals. But I have never been able to get .frame to actually set the context like this. What I have done is to manually change the rsp field in the in-memory trap frame (add the 0x118 to it) and then do .trap on that address again. At this point the Calls window shows the correct stack and now I can jump between frames either in that window or by issuing .frame /r 3, etc.
So I have a workaround, this just seems a bit hacky to do what, presumably, the .frame /r /c = command is designed for. The other thing I don't understand is, why is it enough to just give kb the rsp, or to only modify the rsp in the trap and get a proper stack, yet .frame wants all 3 (rbp, rsp, rip)?
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|
I've never tried the .frame thing, but it sounds to me like you're not generating the correct unwind data for your assembly routine. For example, see .ALLOCSTACK: