microsoftfeedback / WinDbg-Feedback

Public issue and feedback tracking for WinDbg Preview.
Creative Commons Attribution 4.0 International
49 stars 12 forks source link

Setting register values does not work #83

Open bearmate opened 2 years ago

bearmate commented 2 years ago

It seems changing the value of registers (at least when analyzing a crash dump) is not possible. Attempting to change a register with the r command or in an extension with the IDebugRegisters::SetValue function returns no error, but doesn't do anything. When attempting to set the register value using the "Registers" window in the UI the value will be displayed in red (like a changed value), but the actual value remains unchanged.

Tested with: Debugger client version: 1.2206.19001.0 Debugger engine version: 10.0.25136.1001

lzybkr commented 2 years ago

Agreed, modifying a register with a dump target should fail.

We'll take a look and see how hard this might be to fix, but no guarantees. It's crazy how often we discover clients that depend on implementation quirks like this.

bearmate commented 2 years ago

We'll take a look and see how hard this might be to fix, but no guarantees. It's crazy how often we discover clients that depend on implementation quirks like this.

I must admit I have dependent on the particular implementation quirks of the old WinDbg for this scenario in the past (I'm very sorry) in WinDbg extensions I wrote. I do think modifying register values in a dump analysis session might be useful, I used it to recreate the specific execution context (saved by setjmp or similar custom mechanisms) of error situations before the crash was triggered. In particular by resetting rip, rsp, rbp etc. to recreate the callstack of the moment the error occured. Failing when a register is reset in a dump target seems reasonable and correct to me, however I would need to search for a different solution for my usecase.

I mainly discovered this behavior and created the issue, because my extensions failed to work with WinDbg Preview, because the behavior has changed compared to old WinDbg.

karthikmacherla commented 2 years ago

Just wanted to follow up on the current issue. Is the problem you're having primarily UI related? It seems that the registers are being set at the engine level, (visible via the r command) although they aren't updated when set on the UI Pane.

In a dump, I tried running:

> r rbx=0x00034
> r rbx  
// displays rbx=0000000000000034

Is your problem only with the windbg UI or also the engine? Also, would you be able to provide more info on how you're using the registers once they are changed in the dump analysis/what commands are no longer working as a result?

bearmate commented 2 years ago

Is your problem only with the windbg UI or also the engine? Also, would you be able to provide more info on how you're using the registers once they are changed in the dump analysis/what commands are no longer working as a result?

It seems to be a problem with the engine. Even if I set the register with for example r rbx=0x00034 and query it with r rbx it remains on it's old value. Same applies when I attempt to set the register in an extension when calling IDebugRegisters::SetValue directly. There is also no warning or error printed or returned by the function. Note that I tested this in a kernel dump file, it might not be a problem on different targets.

My main use case is to restore a different cpu context (which was the cause of the crash, before KeBugCheck was explicitly triggered). In the old WinDbg resetting the registers also immediately updates the call stack according to rip, rbp, rsp etc. which is very useful.