Re: Changing local variables in WinDbg does not affect target system

WINDBG
1

Hello!

I wanted to change the ntstatus variable from STATUS_SUCCESS (0x0) to
STATUS_TIMEOUT (0x102) to check the error handling in my legacy filter
driver.

I cannot attach a picture so I will paste you some lines first:
Command window:
ntStatus:0x0

Locals window:
ntStatus 258 long b9ea0b68

Code:
DbgPrint(“ntStatus:0x%x”, ntStatus);

The ntstatus was printed to WinDBG (using DbgPrint) after I changed it
from 0x0 to 0x102 in the “Locals” window, which shows the correct
(changed) value.
The memory window also shows the new value:
b9ea0b68 02 01 00 00

Have anybody seen anything like this?

I have rebuilt the filter modile, restarted both (host and target)
machines - just in case - but it without any success.

I was able to change some variables before and I did not see any problems.

Is it possible that it is a WinDbg bug? Maybe WinDbg does not link the
ntStatus variable to appropriate memory location.

Regards,
Urban

2

Less likely this is a bug in windbg. Since this is a local, and you
mentioned you rebuilt the driver, I am assuming you changed code to
assign ntStatus to 0x102 in your code. Make sure you are running in
debug and your driver is indeed updated.

Satya

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Urban Purkat
Sent: Monday, March 06, 2006 6:50 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Changing local variables in WinDbg does not affect
target system

Is it possible that it is a WinDbg bug? Maybe WinDbg does not link the
ntStatus variable to appropriate memory location.

3

Urban Purkat wrote:

ntStatus 258 long b9ea0b68

Code:
DbgPrint(“ntStatus:0x%x”, ntStatus);

The ntstatus was printed to WinDBG (using DbgPrint) after I changed it
from 0x0 to 0x102 in the “Locals” window, which shows the correct

What is the problem? I see ntStatus having the value 258, which is
decimal for 0x102. What do you think it SHOULD do?

Cheers,

/ h+

4

Jon Watte wrote:

Urban Purkat wrote:

> ntStatus 258 long b9ea0b68

> Code:
> DbgPrint(“ntStatus:0x%x”, ntStatus);
>
> The ntstatus was printed to WinDBG (using DbgPrint) after I changed it
> from 0x0 to 0x102 in the “Locals” window, which shows the correct

What is the problem? I see ntStatus having the value 258, which is
decimal for 0x102. What do you think it SHOULD do?

I had written the exact same reply, until I re-read his message for the
third time. Note the lines you did NOT quote:

I cannot attach a picture so I will paste you some lines first:
Command window:
ntStatus:0x0

Locals window:
ntStatus 258 long b9ea0b68

Code:
DbgPrint(“ntStatus:0x%x”, ntStatus);

When he says “Command window”, I think he’s saying “the result of my
DbgPrint”. It’s still showing 0.

There are several possible explanations. The original (0) ntStatus
could have been moved into a register or pushed on the stack already by
the time he changed it. WinDBG wouldn’t know that.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Hi, all.

I am sure that I run the debug version of the module.

I had written the exact same reply, until I re-read his message for the
third time. Note the lines you did NOT quote:

>I cannot attach a picture so I will paste you some lines first:
>Command window:
>ntStatus:0x0
>
>Locals window:
>ntStatus 258 long b9ea0b68
>
>Code:
>DbgPrint(“ntStatus:0x%x”, ntStatus);
>

When he says “Command window”, I think he’s saying “the result of my
DbgPrint”. It’s still showing 0.
Yes, Tim, you are correct. Actually it is not the DbgPrint Output that
borthers me, but later in the code I use the ntStatus variable to
decide what to do.

There are several possible explanations. The original (0) ntStatus
could have been moved into a register or pushed on the stack already by
the time he changed it. WinDBG wouldn’t know that.

Ok maybe I should provide more code:

— cut —
ntStatus = MyFunctionThatReturnsNtStatus();

if ((STATUS_TIMEOUT == ntStatus)
|| (STATUS_DELETE_PENDING == ntStatus)
|| (STATUS_FILE_DELETED == ntStatus))
{
// some lines are skipped - error handling
ntStatus = STATUS_SUCCESS;
}

DbgPrint(“ntStatus:0x%x”, ntStatus);

if (ntStatus != STATUS_SUCCESS)
{
REPORT_ERROR_m(…);
goto cleanup;
};
— cut —

And now some comments:
The function MyFunctionThatReturnsNtStatus() should normally return
STATUS_SUCCESS (0) but I can change the ntStatus variable just after
the call (before the first if) and the if sentence is skipped. That’s
why I added a DbgPrint line after it.

I have tried several things, but I cannot figure out what could be wrong.

Urban

6

Can anyone help me here?

I have mase some more tests. I change two different variables at the
same time (using Local wondow) and the ntStatus variable change does
not attecf the system but the other does.

Regards,
Urban

On 3/7/06, Urban Purkat wrote:
> Hi, all.
>
> I am sure that I run the debug version of the module.
>
> > I had written the exact same reply, until I re-read his message for the
> > third time. Note the lines you did NOT quote:
> >
> > >I cannot attach a picture so I will paste you some lines first:
> > >Command window:
> > >ntStatus:0x0
> > >
> > >Locals window:
> > >ntStatus 258 long b9ea0b68
> > >
> > >Code:
> > >DbgPrint(“ntStatus:0x%x”, ntStatus);
> > >
> >
> > When he says “Command window”, I think he’s saying “the result of my
> > DbgPrint”. It’s still showing 0.
> Yes, Tim, you are correct. Actually it is not the DbgPrint Output that
> borthers me, but later in the code I use the ntStatus variable to
> decide what to do.
>
>
> > There are several possible explanations. The original (0) ntStatus
> > could have been moved into a register or pushed on the stack already by
> > the time he changed it. WinDBG wouldn’t know that.
>
> Ok maybe I should provide more code:
>
> — cut —
> ntStatus = MyFunctionThatReturnsNtStatus();
>
> if ((STATUS_TIMEOUT == ntStatus)
> || (STATUS_DELETE_PENDING == ntStatus)
> || (STATUS_FILE_DELETED == ntStatus))
> {
> // some lines are skipped - error handling
> ntStatus = STATUS_SUCCESS;
> }
>
> DbgPrint(“ntStatus:0x%x”, ntStatus);
>
> if (ntStatus != STATUS_SUCCESS)
> {
> REPORT_ERROR_m(…);
> goto cleanup;
> };
> — cut —
>
> And now some comments:
> The function MyFunctionThatReturnsNtStatus() should normally return
> STATUS_SUCCESS (0) but I can change the ntStatus variable just after
> the call (before the first if) and the if sentence is skipped. That’s
> why I added a DbgPrint line after it.
>
> I have tried several things, but I cannot figure out what could be wrong.
>
> Urban
>

7

Urban,
It sounds like you could make further progress in understanding this
if you look at the assembly language view, and/or step it in assembly
language mode.

Or to work around the problem without understanding it: breakpoint
at the end of the called routine. Arrange for it to return the
simulated status.

Best regards,
David

At 08:22 AM 3/9/2006 +0100, you wrote:

Can anyone help me here?

I have mase some more tests. I change two different variables at the
same time (using Local wondow) and the ntStatus variable change does
not attecf the system but the other does.

Regards,
Urban

On 3/7/06, Urban Purkat wrote:
> > Hi, all.
> >
> > I am sure that I run the debug version of the module.
> >
> > > I had written the exact same reply, until I re-read his message for the
> > > third time. Note the lines you did NOT quote:
> > >
> > > >I cannot attach a picture so I will paste you some lines first:
> > > >Command window:
> > > >ntStatus:0x0
> > > >
> > > >Locals window:
> > > >ntStatus 258 long b9ea0b68
> > > >
> > > >Code:
> > > >DbgPrint(“ntStatus:0x%x”, ntStatus);
> > > >
> > >
> > > When he says “Command window”, I think he’s saying “the result of my
> > > DbgPrint”. It’s still showing 0.
> > Yes, Tim, you are correct. Actually it is not the DbgPrint Output that
> > borthers me, but later in the code I use the ntStatus variable to
> > decide what to do.
> >
> >
> > > There are several possible explanations. The original (0) ntStatus
> > > could have been moved into a register or pushed on the stack already by
> > > the time he changed it. WinDBG wouldn’t know that.
> >
> > Ok maybe I should provide more code:
> >
> > — cut —
> > ntStatus = MyFunctionThatReturnsNtStatus();
> >
> > if ((STATUS_TIMEOUT == ntStatus)
> > || (STATUS_DELETE_PENDING == ntStatus)
> > || (STATUS_FILE_DELETED == ntStatus))
> > {
> > // some lines are skipped - error handling
> > ntStatus = STATUS_SUCCESS;
> > }
> >
> > DbgPrint(“ntStatus:0x%x”, ntStatus);
> >
> > if (ntStatus != STATUS_SUCCESS)
> > {
> > REPORT_ERROR_m(…);
> > goto cleanup;
> > };
> > — cut —
> >
> > And now some comments:
> > The function MyFunctionThatReturnsNtStatus() should normally return
> > STATUS_SUCCESS (0) but I can change the ntStatus variable just after
> > the call (before the first if) and the if sentence is skipped. That’s
> > why I added a DbgPrint line after it.
> >
> > I have tried several things, but I cannot figure out what could be wrong.
> >
> > Urban
> >
>
>
>—
>You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Urban Purkat wrote:

Can anyone help me here?

I have mase some more tests. I change two different variables at the
same time (using Local wondow) and the ntStatus variable change does
not attecf the system but the other does.

There are just too many “variables” here. At the specific spot where
you change the value in the local window, it’s possible that the
ntStatus value has already been loaded into a register or pushed onto a
stack. Or, perhaps the value returned is still in a register and is
waiting to be written to memory. Windbg’s debugger doesn’t necessarily
have that kind of detailed information. You need to help it out, by
looking through the disassembled x86 code, to make sure that the value
is really getting set where it needs to be set.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

> There are just too many “variables” here. At the specific spot where

you change the value in the local window, it’s possible that the
ntStatus value has already been loaded into a register or pushed onto a
stack. Or, perhaps the value returned is still in a register and is
waiting to be written to memory.

I have already thought of it but I was not sure if I am correct. But
there is obviously no other explanation for such behaviour.

Thanks for your answers.

Rgards,
Urban