Fwd: analysing a funny stack trace

Ohh it seems it is like this because of FPO? :slight_smile:

---------- Forwarded message ----------
From: NTFSD-List
Date: Sep 9, 2005 12:28 AM
Subject: analysing a funny stack trace
To: Windows File Systems Devs Interest List

Hi,
We observed a deadlock today because of our filter driver and windbg showed
the following backtrace. It was diagnosed to the fact
that we were calling ZwCreateFile while holding a fast-mutex. This disabled
APC delivery as a result of which the requesting thread was never woken up
again. We fixed this and things seems to be fine.
However, what is puzzling me is the 1st argument to KeWaitForSingleObject
which is 0? Does anyone know what is happening?
Thanks
ChildEBP RetAddr Args to Child

f4784124 8083ca79 85405e18 85405da8 80831c80 nt!KiSwapContext+0x2f (FPO:

[Uses EBP] [0,0,4])

f4784130 80831c80 00000103 f47841cc 00000000 nt!KiSwapThread+0x6b (FPO:

[0,0,0])

f4784158 f58dd7df 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x22e

(FPO: [Non-Fpo])

f4784198 f58ecb47 86489368 00024800 866a36c8 Cdfs!CdPerformDevIoCtrl+0xb3

(FPO: [Non-Fpo])

f47841e0 f58dc7b3 86489368 85306bc8 aed50eb8 Cdfs!CdVerifyVcb+0xad (FPO:

[Non-Fpo])

f478456c f58d3d3a 86489368 aed50eb8 85306af8 Cdfs!CdCommonCreate+0x1e5 (FPO:

[Non-Fpo])

f47845c4 8081fa73 85306af8 aed50eb8 85306af8 Cdfs!CdFsdDispatch+0x126 (FPO:

[Non-Fpo])

f47845dc 80ae0128 86094020 aed50eb8 00000000 nt!IopfCallDriver+0x51 (FPO:

[0,0,0])

f4784600 bb46957c 86094020 aed50eb8 00000000 nt!IovCallDriver+0xa0 (FPO:

No, it is more likely that that value on the stack has changed.

For example, imagine you had a function like:

MyFunction(PVOID Foo, …)

{

/* lots of code */

Foo = 0;

}

If you then took a stack trace, you’d see zero on the stack - that
doesn’t mean it was the value when the function was called, just that
this is the value on the stack at the time you are looking.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of NTFSD-List
Sent: Thursday, September 08, 2005 3:07 PM
To: ntfsd redirect
Subject: [ntfsd] Fwd: analysing a funny stack trace

Ohh it seems it is like this because of FPO? :slight_smile:

---------- Forwarded message ----------
From: NTFSD-List
Date: Sep 9, 2005 12:28 AM
Subject: analysing a funny stack trace
To: Windows File Systems Devs Interest List

Hi,

We observed a deadlock today because of our filter driver and windbg
showed the following backtrace. It was diagnosed to the fact

that we were calling ZwCreateFile while holding a fast-mutex. This
disabled APC delivery as a result of which the requesting thread was
never woken up again. We fixed this and things seems to be fine.

However, what is puzzling me is the 1st argument to
KeWaitForSingleObject which is 0? Does anyone know what is happening?

Thanks

ChildEBP RetAddr Args to Child

f4784124 8083ca79 85405e18 85405da8 80831c80 nt!KiSwapContext+0x2f (FPO:

[Uses EBP] [0,0,4])

f4784130 80831c80 00000103 f47841cc 00000000 nt!KiSwapThread+0x6b (FPO:

[0,0,0])

f4784158 f58dd7df 00000000 00000000 00000000
nt!KeWaitForSingleObject+0x22e

(FPO: [Non-Fpo])

f4784198 f58ecb47 86489368 00024800 866a36c8
Cdfs!CdPerformDevIoCtrl+0xb3

(FPO: [Non-Fpo])

f47841e0 f58dc7b3 86489368 85306bc8 aed50eb8 Cdfs!CdVerifyVcb+0xad (FPO:

[Non-Fpo])

f478456c f58d3d3a 86489368 aed50eb8 85306af8 Cdfs!CdCommonCreate+0x1e5
(FPO:

[Non-Fpo])

f47845c4 8081fa73 85306af8 aed50eb8 85306af8 Cdfs!CdFsdDispatch+0x126
(FPO:

[Non-Fpo])

f47845dc 80ae0128 86094020 aed50eb8 00000000 nt!IopfCallDriver+0x51
(FPO:

[0,0,0])

f4784600 bb46957c 86094020 aed50eb8 00000000 nt!IovCallDriver+0xa0 (FPO:

— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com

> No, it is more likely that that value on the stack has changed.

For example, imagine you had a function like:

I can confirm it. Also sometimes the code is optimized that
instead to storing to a local variable (EBP-X), a value is stored to
a parameter variable (EBP+X), if the parameter isn’t used anymore.

MyFunction(PVOID Foo, .)

{

PVOID Foo2;

Foo2 = XxMakeSomethingWithFoo(Foo);

// Foo is not used anymore - it is probable the the Foo2

// will be stored into Foo.

}

L.

Another reason for this to be observed is the compiler when optimizing your
code will reuse the actuals as temporaries. For example:

MyFunction(PVOID foo)
{
int a, b;

a = foo->var;

b = a;
}

When you look at the generated code, you may see “foo” moved to a reg (say
ESI) and then ‘a’ stored ontop of foo because optimized code saves stack
frames too! (A real pain to debug optimized code sometimes)

Something like:

mov esi, [foo]
mov eax,[esi + var]
mov [foo],eax

/ted

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Thursday, September 08, 2005 3:20 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Fwd: analysing a funny stack trace

No, it is more likely that that value on the stack has changed.

For example, imagine you had a function like:

MyFunction(PVOID Foo, …)

{

/* lots of code */

Foo = 0;

}

If you then took a stack trace, you’d see zero on the stack - that doesn’t
mean it was the value when the function was called, just that this is the
value on the stack at the time you are looking.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of NTFSD-List
Sent: Thursday, September 08, 2005 3:07 PM
To: ntfsd redirect
Subject: [ntfsd] Fwd: analysing a funny stack trace

Ohh it seems it is like this because of FPO? :slight_smile:

---------- Forwarded message ----------
From: NTFSD-List >
Date: Sep 9, 2005 12:28 AM
Subject: analysing a funny stack trace
To: Windows File Systems Devs Interest List mailto:xxxxx >

Hi,

We observed a deadlock today because of our filter driver and windbg showed
the following backtrace. It was diagnosed to the fact

that we were calling ZwCreateFile while holding a fast-mutex. This disabled
APC delivery as a result of which the requesting thread was never woken up
again. We fixed this and things seems to be fine.

However, what is puzzling me is the 1st argument to KeWaitForSingleObject
which is 0? Does anyone know what is happening?

Thanks

ChildEBP RetAddr Args to Child

f4784124 8083ca79 85405e18 85405da8 80831c80 nt!KiSwapContext+0x2f (FPO:

[Uses EBP] [0,0,4])

f4784130 80831c80 00000103 f47841cc 00000000 nt!KiSwapThread+0x6b (FPO:

[0,0,0])

f4784158 f58dd7df 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x22e

(FPO: [Non-Fpo])

f4784198 f58ecb47 86489368 00024800 866a36c8 Cdfs!CdPerformDevIoCtrl+0xb3

(FPO: [Non-Fpo])

f47841e0 f58dc7b3 86489368 85306bc8 aed50eb8 Cdfs!CdVerifyVcb+0xad (FPO:

[Non-Fpo])

f478456c f58d3d3a 86489368 aed50eb8 85306af8 Cdfs!CdCommonCreate+0x1e5 (FPO:

[Non-Fpo])

f47845c4 8081fa73 85306af8 aed50eb8 85306af8 Cdfs!CdFsdDispatch+0x126 (FPO:

[Non-Fpo])

f47845dc 80ae0128 86094020 aed50eb8 00000000 nt!IopfCallDriver+0x51 (FPO:

[0,0,0])

f4784600 bb46957c 86094020 aed50eb8 00000000 nt!IovCallDriver+0xa0 (FPO:

— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>