Reply Separator
Subject: Re: (ntdev) Utterly mystified by this bugcheck.
Author: “Mats PETERSSON” smtp:xxxxx
Date: 13/12/2004 11:15
> However, I’d also ask whether this code is actually pageable or not, because
if
> it’s actually pageable, then you DO have a problem. The assert in the code
> should fire if you’re in pageable code too.
There are no explicit pragmas in the code to make it pageable, and I was taking
it on the authority of the map file that the code is not, since the map file
puts the function in section 1 (.text) instead of section 4 (PAGE).
Is there a way of determining whether a particular part of the code address
space is pageable at runtime?
> Are you running with driver verifier? If not, turn it on, it may help…
Yes, I am - all my drivers run with the verifier permanently on, and all
checking enabled except low resource simulation.
> Disassembly of the whole function (up til the point where it falls over at
> least) would be helpful.
Okay. Included at the bottom of this mail. I have taken the liberty of reading
the assembler, and interspersing the code at appropriate points, so it’s easier
to see what is going on.
> Note: The operation you’re performing (mov [ebp-0x5],al) is a WRITE operation,
> and your bug check indicates a “READ” operation, which means to me that the OS
> trapped the instruction read rather than the EBP operation. This rules out the
> stack being munged, which was my first thought…
Yes, looking at the fault addresses in the bug check, it appears that it’s
actually the fetch for the instruction stream that’s faulting.
> Does this happen immediately or after some time?
It happens very rarely, but when it does, it tends to occur on driver start-up
at boot time - I actually have about 10-20 devices that create system threads in
quick succession when the system is started up.
Having said that, I have seen this before: I managed to get it to occur when
there was a bug in the original code (incorrectly using the wrong type of event
- a notification event instead of a synchronization event), which meant that the
thread simply spun round and round, aquiring and releasing the spinlock.
I simply attributed the bug to the fact I was doing something stupid with a
system thread (busy loop aquiring and releasing lock) - however, it looks like
there is another problem, and I should have looked into it more carefully.
many thanks for your reply.
Martin H.
mediaxImx!WorkerThreadFn:
VOID WorkerThreadFn(PVOID Context)
{
PSTREAM_WORK_POOL pPool = (PSTREAM_WORK_POOL) Context;
ULONG NextToCheck = 0;
KIRQL Irql;
BOOL DidWork; //Flag that allows us to determine that last time
push ebp
mov ebp,esp
sub esp,0x14
mov eax,[ebp+0x8]
mov [ebp-0xc],eax
mov dword ptr [ebp-0x4],0x0
KdPrint2((“%s: WorkerThreadFn Start.\n”, gDriverName));
mov ecx,[mediaxImx!gDebugLevel (f1d21410)]
and ecx,0x2
jz mediaxImx!WorkerThreadFn+0x30 (f1d204e0)
push 0xf1d21324
push 0xf1d20270
call mediaxImx!DbgPrint (f1d1a1fe)
add esp,0x8
PAGED_CODE();
xor edx,edx
jnz mediaxImx!WorkerThreadFn+0x13 (f1d204c3)
call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
movzx eax,al
cmp eax,0x1
jle mediaxImx!WorkerThreadFn+0x79 (f1d20529)
call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
movzx ecx,al
push ecx
push 0xf1d2028c
call mediaxImx!DbgPrint (f1d1a1fe)
add esp,0x8
mov edx,0x1
test edx,edx
jz mediaxImx!WorkerThreadFn+0x79 (f1d20529)
push 0x0
push 0xe1
push 0xf1d202b4
push 0xf1d202ec
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
ASSERT(pPool);
cmp dword ptr [ebp-0xc],0x0
jnz mediaxImx!WorkerThreadFn+0x96 (f1d20546)
push 0x0
push 0xe2
push 0xf1d202f4
push 0xf1d2032c
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
ASSERT(pPool->InitFlag == POOL_INIT_FLAG);
mov eax,[ebp-0xc]
cmp dword ptr [eax],0x12344321
jz mediaxImx!WorkerThreadFn+0xb8 (f1d20568)
push 0x0
push 0xe3
push 0xf1d20334
push 0xf1d2036c
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
KeAcquireSpinLock(&pPool->DataLock, &Irql);
mov ecx,[ebp-0xc]
add ecx,0x4
call dword ptr [mediaxImx!_imp_KfAcquireSpinLock (f1d20800)]
mov [ebp-0x5],al
while(1)
{
mov ecx,0x1
test ecx,ecx
je mediaxImx!WorkerThreadFn+0x298 (f1d20748)
DidWork = FALSE;
mov dword ptr [ebp-0x10],0x0
for (NextToCheck = 0; NextToCheck < MAX_WORKER_STREAMS; NextToCheck++)
{
mov dword ptr [ebp-0x4],0x0
jmp mediaxImx!WorkerThreadFn+0xed (f1d2059d)
mov edx,[ebp-0x4]
add edx,0x1
mov [ebp-0x4],edx
cmp dword ptr [ebp-0x4],0x8
jnb mediaxImx!WorkerThreadFn+0x203 (f1d206b3)
<…more code here…>
mov eax,[ebp-0x4]
imul eax,eax,0x28
mov ecx,[ebp-0xc]
lea edx,[ecx+eax+0xc]
mov [ebp-0x14],edx
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.</smtp:xxxxx>
To clarify, the instruction that bugchecks is the instruction that
immediately follows your call to KeAcquireSpinlock()?
Also note this line from your original post:
READ_ADDRESS: f1881574 Nonpaged pool
0xf1881574 of course being the address of the bugchecking instruction.
Is it just me or does this mean that address really is not paged?
Although the symptom seems to indicate your code is missing when
KeAcquireSpinlock() returns. Weird!
This is a long shot, but is there any chance that something is
overwriting the code in your driver? Perhaps, for example, a debugger
putting a soft break point at address 0xf1881574?
Chuck
----- Original Message -----
From: “M Harvey”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 13, 2004 7:15 PM
Subject: RE:[ntdev] (ntdev) Utterly mystified by this bugcheck.
Reply Separator
Subject: Re: (ntdev) Utterly mystified by this bugcheck.
Author: “Mats PETERSSON” smtp:xxxxx
Date: 13/12/2004 11:15
> However, I’d also ask whether this code is actually pageable or not,
> because
if
> it’s actually pageable, then you DO have a problem. The assert in the
> code
> should fire if you’re in pageable code too.
There are no explicit pragmas in the code to make it pageable, and I was
taking
it on the authority of the map file that the code is not, since the map
file
puts the function in section 1 (.text) instead of section 4 (PAGE).
Is there a way of determining whether a particular part of the code
address
space is pageable at runtime?
> Are you running with driver verifier? If not, turn it on, it may
> help…
Yes, I am - all my drivers run with the verifier permanently on, and all
checking enabled except low resource simulation.
> Disassembly of the whole function (up til the point where it falls
> over at
> least) would be helpful.
Okay. Included at the bottom of this mail. I have taken the liberty of
reading
the assembler, and interspersing the code at appropriate points, so it’s
easier
to see what is going on.
> Note: The operation you’re performing (mov [ebp-0x5],al) is a WRITE
> operation,
> and your bug check indicates a “READ” operation, which means to me
> that the OS
> trapped the instruction read rather than the EBP operation. This rules
> out the
> stack being munged, which was my first thought…
Yes, looking at the fault addresses in the bug check, it appears that
it’s
actually the fetch for the instruction stream that’s faulting.
> Does this happen immediately or after some time?
It happens very rarely, but when it does, it tends to occur on driver
start-up
at boot time - I actually have about 10-20 devices that create system
threads in
quick succession when the system is started up.
Having said that, I have seen this before: I managed to get it to
occur when
there was a bug in the original code (incorrectly using the wrong type
of event
- a notification event instead of a synchronization event), which meant
that the
thread simply spun round and round, aquiring and releasing the spinlock.
I simply attributed the bug to the fact I was doing something stupid
with a
system thread (busy loop aquiring and releasing lock) - however, it
looks like
there is another problem, and I should have looked into it more
carefully.
many thanks for your reply.
Martin H.
mediaxImx!WorkerThreadFn:
VOID WorkerThreadFn(PVOID Context)
{
PSTREAM_WORK_POOL pPool = (PSTREAM_WORK_POOL) Context;
ULONG NextToCheck = 0;
KIRQL Irql;
BOOL DidWork; //Flag that allows us to determine that last time
push ebp
mov ebp,esp
sub esp,0x14
mov eax,[ebp+0x8]
mov [ebp-0xc],eax
mov dword ptr [ebp-0x4],0x0
KdPrint2((“%s: WorkerThreadFn Start.\n”, gDriverName));
mov ecx,[mediaxImx!gDebugLevel (f1d21410)]
and ecx,0x2
jz mediaxImx!WorkerThreadFn+0x30 (f1d204e0)
push 0xf1d21324
push 0xf1d20270
call mediaxImx!DbgPrint (f1d1a1fe)
add esp,0x8
PAGED_CODE();
xor edx,edx
jnz mediaxImx!WorkerThreadFn+0x13 (f1d204c3)
call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
movzx eax,al
cmp eax,0x1
jle mediaxImx!WorkerThreadFn+0x79 (f1d20529)
call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
movzx ecx,al
push ecx
push 0xf1d2028c
call mediaxImx!DbgPrint (f1d1a1fe)
add esp,0x8
mov edx,0x1
test edx,edx
jz mediaxImx!WorkerThreadFn+0x79 (f1d20529)
push 0x0
push 0xe1
push 0xf1d202b4
push 0xf1d202ec
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
ASSERT(pPool);
cmp dword ptr [ebp-0xc],0x0
jnz mediaxImx!WorkerThreadFn+0x96 (f1d20546)
push 0x0
push 0xe2
push 0xf1d202f4
push 0xf1d2032c
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
ASSERT(pPool->InitFlag == POOL_INIT_FLAG);
mov eax,[ebp-0xc]
cmp dword ptr [eax],0x12344321
jz mediaxImx!WorkerThreadFn+0xb8 (f1d20568)
push 0x0
push 0xe3
push 0xf1d20334
push 0xf1d2036c
call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
KeAcquireSpinLock(&pPool->DataLock, &Irql);
mov ecx,[ebp-0xc]
add ecx,0x4
call dword ptr [mediaxImx!_imp_KfAcquireSpinLock (f1d20800)]
mov [ebp-0x5],al
while(1)
{
mov ecx,0x1
test ecx,ecx
je mediaxImx!WorkerThreadFn+0x298 (f1d20748)
DidWork = FALSE;
mov dword ptr [ebp-0x10],0x0
for (NextToCheck = 0; NextToCheck < MAX_WORKER_STREAMS;
NextToCheck++)
{
mov dword ptr [ebp-0x4],0x0
jmp mediaxImx!WorkerThreadFn+0xed (f1d2059d)
mov edx,[ebp-0x4]
add edx,0x1
mov [ebp-0x4],edx
cmp dword ptr [ebp-0x4],0x8
jnb mediaxImx!WorkerThreadFn+0x203 (f1d206b3)
<…more code here…>
mov eax,[ebp-0x4]
imul eax,eax,0x28
mov ecx,[ebp-0xc]
lea edx,[ecx+eax+0xc]
mov [ebp-0x14],edx</smtp:xxxxx>
How would overwriting the address change anything?
It’s still failing on the instruction featch and as a READ. If the
something was overwriting the instruction, it would either show a different
disassembly, or fail on the WRITE operation.
Unless of course the memory is allocated as “Copy on write”, and the copy
is what fails… Seems strange to me.
This is of course just my thoughts, I think Martin should check carefully
that the code isn’t being overwritten, but at the same time, I don’t think
that’s the problem.
–
Mats
xxxxx@lists.osr.com wrote on 12/13/2004 01:14:42 PM:
To clarify, the instruction that bugchecks is the instruction that
immediately follows your call to KeAcquireSpinlock()?Also note this line from your original post:
READ_ADDRESS: f1881574 Nonpaged pool
0xf1881574 of course being the address of the bugchecking instruction.
Is it just me or does this mean that address really is not paged?
Although the symptom seems to indicate your code is missing when
KeAcquireSpinlock() returns. Weird!This is a long shot, but is there any chance that something is
overwriting the code in your driver? Perhaps, for example, a debugger
putting a soft break point at address 0xf1881574?Chuck
----- Original Message -----
From: “M Harvey”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, December 13, 2004 7:15 PM
> Subject: RE:[ntdev] (ntdev) Utterly mystified by this bugcheck.
>
>
>
>
> Reply Separator
> Subject: Re: (ntdev) Utterly mystified by this bugcheck.
> Author: “Mats PETERSSON” smtp:xxxxx
> Date: 13/12/2004 11:15
>
> > However, I’d also ask whether this code is actually pageable or not,
> > because
> if
> > it’s actually pageable, then you DO have a problem. The assert in the
> > code
> > should fire if you’re in pageable code too.
>
> There are no explicit pragmas in the code to make it pageable, and I was
> taking
> it on the authority of the map file that the code is not, since the map
> file
> puts the function in section 1 (.text) instead of section 4 (PAGE).
>
> Is there a way of determining whether a particular part of the code
> address
> space is pageable at runtime?
>
> > Are you running with driver verifier? If not, turn it on, it may
> > help…
>
> Yes, I am - all my drivers run with the verifier permanently on, and all
> checking enabled except low resource simulation.
>
> > Disassembly of the whole function (up til the point where it falls
> > over at
> > least) would be helpful.
>
> Okay. Included at the bottom of this mail. I have taken the liberty of
> reading
> the assembler, and interspersing the code at appropriate points, so it’s
> easier
> to see what is going on.
>
> > Note: The operation you’re performing (mov [ebp-0x5],al) is a WRITE
> > operation,
> > and your bug check indicates a “READ” operation, which means to me
> > that the OS
> > trapped the instruction read rather than the EBP operation. This rules
> > out the
> > stack being munged, which was my first thought…
>
> Yes, looking at the fault addresses in the bug check, it appears that
> it’s
> actually the fetch for the instruction stream that’s faulting.
>
> > Does this happen immediately or after some time?
>
> It happens very rarely, but when it does, it tends to occur on driver
> start-up
> at boot time - I actually have about 10-20 devices that create system
> threads in
> quick succession when the system is started up.
>
> Having said that, I have seen this before: I managed to get it to
> occur when
> there was a bug in the original code (incorrectly using the wrong type
> of event
> - a notification event instead of a synchronization event), which meant
> that the
> thread simply spun round and round, aquiring and releasing the spinlock.
>
> I simply attributed the bug to the fact I was doing something stupid
> with a
> system thread (busy loop aquiring and releasing lock) - however, it
> looks like
> there is another problem, and I should have looked into it more
> carefully.
>
> many thanks for your reply.
>
> Martin H.
>
>
>
> mediaxImx!WorkerThreadFn:
>
> VOID WorkerThreadFn(PVOID Context)
> {
> PSTREAM_WORK_POOL pPool = (PSTREAM_WORK_POOL) Context;
> ULONG NextToCheck = 0;
> KIRQL Irql;
> BOOL DidWork; //Flag that allows us to determine that last time
>
>
> push ebp
> mov ebp,esp
> sub esp,0x14
> mov eax,[ebp+0x8]
> mov [ebp-0xc],eax
> mov dword ptr [ebp-0x4],0x0
>
> KdPrint2((“%s: WorkerThreadFn Start.\n”, gDriverName));
>
> mov ecx,[mediaxImx!gDebugLevel (f1d21410)]
> and ecx,0x2
> jz mediaxImx!WorkerThreadFn+0x30 (f1d204e0)
> push 0xf1d21324
> push 0xf1d20270
> call mediaxImx!DbgPrint (f1d1a1fe)
> add esp,0x8
>
> PAGED_CODE();
>
> xor edx,edx
> jnz mediaxImx!WorkerThreadFn+0x13 (f1d204c3)
> call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
> movzx eax,al
> cmp eax,0x1
> jle mediaxImx!WorkerThreadFn+0x79 (f1d20529)
> call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
> movzx ecx,al
> push ecx
> push 0xf1d2028c
> call mediaxImx!DbgPrint (f1d1a1fe)
> add esp,0x8
> mov edx,0x1
> test edx,edx
> jz mediaxImx!WorkerThreadFn+0x79 (f1d20529)
> push 0x0
> push 0xe1
> push 0xf1d202b4
> push 0xf1d202ec
> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>
> ASSERT(pPool);
>
> cmp dword ptr [ebp-0xc],0x0
> jnz mediaxImx!WorkerThreadFn+0x96 (f1d20546)
> push 0x0
> push 0xe2
> push 0xf1d202f4
> push 0xf1d2032c
> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>
> ASSERT(pPool->InitFlag == POOL_INIT_FLAG);
>
> mov eax,[ebp-0xc]
> cmp dword ptr [eax],0x12344321
> jz mediaxImx!WorkerThreadFn+0xb8 (f1d20568)
> push 0x0
> push 0xe3
> push 0xf1d20334
> push 0xf1d2036c
> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>
> KeAcquireSpinLock(&pPool->DataLock, &Irql);
>
> mov ecx,[ebp-0xc]
> add ecx,0x4
> call dword ptr [mediaxImx!_imp_KfAcquireSpinLock (f1d20800)]
> mov [ebp-0x5],al
>
> while(1)
> {
>
> mov ecx,0x1
> test ecx,ecx
> je mediaxImx!WorkerThreadFn+0x298 (f1d20748)
>
> DidWork = FALSE;
>
> mov dword ptr [ebp-0x10],0x0
>
> for (NextToCheck = 0; NextToCheck < MAX_WORKER_STREAMS;
> NextToCheck++)
> {
>
> mov dword ptr [ebp-0x4],0x0
> jmp mediaxImx!WorkerThreadFn+0xed (f1d2059d)
> mov edx,[ebp-0x4]
> add edx,0x1
> mov [ebp-0x4],edx
> cmp dword ptr [ebp-0x4],0x8
> jnb mediaxImx!WorkerThreadFn+0x203 (f1d206b3)
>
> <…more code here…>
>
> mov eax,[ebp-0x4]
> imul eax,eax,0x28
> mov ecx,[ebp-0xc]
> lea edx,[ecx+eax+0xc]
> mov [ebp-0x14],edx
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT00009536</smtp:xxxxx>
Yeah, it’s not altogether likely. My initial thought was that perhaps
if it was a soft breakpoint (i.e. int 3), the CPU might be trying to
fetch a vector that’s paged out but make it look like the driver’s
instruction was at fault. (Of course, why such a vector would be
pageable is beyond me, but I brought it up for lack of a better idea.)
In the end I was too lazy to look at the Intel book to see what exactly
the int instruction does. 
Chuck
----- Original Message -----
From: “Mats PETERSSON”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 13, 2004 8:23 PM
Subject: Re: RE:[ntdev] (ntdev) Utterly mystified by this bugcheck.
>
>
>
>
>
> How would overwriting the address change anything?
>
> It’s still failing on the instruction featch and as a READ. If the
> something was overwriting the instruction, it would either show a
> different
> disassembly, or fail on the WRITE operation.
>
> Unless of course the memory is allocated as “Copy on write”, and the
> copy
> is what fails… Seems strange to me.
>
> This is of course just my thoughts, I think Martin should check
> carefully
> that the code isn’t being overwritten, but at the same time, I don’t
> think
> that’s the problem.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 12/13/2004 01:14:42 PM:
>
>> To clarify, the instruction that bugchecks is the instruction that
>> immediately follows your call to KeAcquireSpinlock()?
>>
>> Also note this line from your original post:
>>
>> READ_ADDRESS: f1881574 Nonpaged pool
>>
>> 0xf1881574 of course being the address of the bugchecking
>> instruction.
>> Is it just me or does this mean that address really is not paged?
>> Although the symptom seems to indicate your code is missing when
>> KeAcquireSpinlock() returns. Weird!
>>
>> This is a long shot, but is there any chance that something is
>> overwriting the code in your driver? Perhaps, for example, a
>> debugger
>> putting a soft break point at address 0xf1881574?
>>
>> Chuck
>>
>> ----- Original Message -----
>> From: “M Harvey”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Monday, December 13, 2004 7:15 PM
>> Subject: RE:[ntdev] (ntdev) Utterly mystified by this bugcheck.
>>
>>
>>
>>
>> Reply Separator
>> Subject: Re: (ntdev) Utterly mystified by this bugcheck.
>> Author: “Mats PETERSSON” smtp:xxxxx
>> Date: 13/12/2004 11:15
>>
>> > However, I’d also ask whether this code is actually pageable or
>> > not,
>> > because
>> if
>> > it’s actually pageable, then you DO have a problem. The assert in
>> > the
>> > code
>> > should fire if you’re in pageable code too.
>>
>> There are no explicit pragmas in the code to make it pageable, and I
>> was
>> taking
>> it on the authority of the map file that the code is not, since the
>> map
>> file
>> puts the function in section 1 (.text) instead of section 4 (PAGE).
>>
>> Is there a way of determining whether a particular part of the code
>> address
>> space is pageable at runtime?
>>
>> > Are you running with driver verifier? If not, turn it on, it may
>> > help…
>>
>> Yes, I am - all my drivers run with the verifier permanently on, and
>> all
>> checking enabled except low resource simulation.
>>
>> > Disassembly of the whole function (up til the point where it falls
>> > over at
>> > least) would be helpful.
>>
>> Okay. Included at the bottom of this mail. I have taken the liberty
>> of
>> reading
>> the assembler, and interspersing the code at appropriate points, so
>> it’s
>> easier
>> to see what is going on.
>>
>> > Note: The operation you’re performing (mov [ebp-0x5],al) is a WRITE
>> > operation,
>> > and your bug check indicates a “READ” operation, which means to me
>> > that the OS
>> > trapped the instruction read rather than the EBP operation. This
>> > rules
>> > out the
>> > stack being munged, which was my first thought…
>>
>> Yes, looking at the fault addresses in the bug check, it appears that
>> it’s
>> actually the fetch for the instruction stream that’s faulting.
>>
>> > Does this happen immediately or after some time?
>>
>> It happens very rarely, but when it does, it tends to occur on driver
>> start-up
>> at boot time - I actually have about 10-20 devices that create system
>> threads in
>> quick succession when the system is started up.
>>
>> Having said that, I have seen this before: I managed to get it to
>> occur when
>> there was a bug in the original code (incorrectly using the wrong
>> type
>> of event
>> - a notification event instead of a synchronization event), which
>> meant
>> that the
>> thread simply spun round and round, aquiring and releasing the
>> spinlock.
>>
>> I simply attributed the bug to the fact I was doing something stupid
>> with a
>> system thread (busy loop aquiring and releasing lock) - however, it
>> looks like
>> there is another problem, and I should have looked into it more
>> carefully.
>>
>> many thanks for your reply.
>>
>> Martin H.
>>
>>
>>
>> mediaxImx!WorkerThreadFn:
>>
>> VOID WorkerThreadFn(PVOID Context)
>> {
>> PSTREAM_WORK_POOL pPool = (PSTREAM_WORK_POOL) Context;
>> ULONG NextToCheck = 0;
>> KIRQL Irql;
>> BOOL DidWork; //Flag that allows us to determine that last time
>>
>>
>> push ebp
>> mov ebp,esp
>> sub esp,0x14
>> mov eax,[ebp+0x8]
>> mov [ebp-0xc],eax
>> mov dword ptr [ebp-0x4],0x0
>>
>> KdPrint2((“%s: WorkerThreadFn Start.\n”, gDriverName));
>>
>> mov ecx,[mediaxImx!gDebugLevel (f1d21410)]
>> and ecx,0x2
>> jz mediaxImx!WorkerThreadFn+0x30 (f1d204e0)
>> push 0xf1d21324
>> push 0xf1d20270
>> call mediaxImx!DbgPrint (f1d1a1fe)
>> add esp,0x8
>>
>> PAGED_CODE();
>>
>> xor edx,edx
>> jnz mediaxImx!WorkerThreadFn+0x13 (f1d204c3)
>> call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
>> movzx eax,al
>> cmp eax,0x1
>> jle mediaxImx!WorkerThreadFn+0x79 (f1d20529)
>> call dword ptr [mediaxImx!_imp__KeGetCurrentIrql (f1d20808)]
>> movzx ecx,al
>> push ecx
>> push 0xf1d2028c
>> call mediaxImx!DbgPrint (f1d1a1fe)
>> add esp,0x8
>> mov edx,0x1
>> test edx,edx
>> jz mediaxImx!WorkerThreadFn+0x79 (f1d20529)
>> push 0x0
>> push 0xe1
>> push 0xf1d202b4
>> push 0xf1d202ec
>> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>>
>> ASSERT(pPool);
>>
>> cmp dword ptr [ebp-0xc],0x0
>> jnz mediaxImx!WorkerThreadFn+0x96 (f1d20546)
>> push 0x0
>> push 0xe2
>> push 0xf1d202f4
>> push 0xf1d2032c
>> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>>
>> ASSERT(pPool->InitFlag == POOL_INIT_FLAG);
>>
>> mov eax,[ebp-0xc]
>> cmp dword ptr [eax],0x12344321
>> jz mediaxImx!WorkerThreadFn+0xb8 (f1d20568)
>> push 0x0
>> push 0xe3
>> push 0xf1d20334
>> push 0xf1d2036c
>> call dword ptr [mediaxImx!_imp__RtlAssert (f1d2085c)]
>>
>> KeAcquireSpinLock(&pPool->DataLock, &Irql);
>>
>> mov ecx,[ebp-0xc]
>> add ecx,0x4
>> call dword ptr [mediaxImx!_imp_KfAcquireSpinLock (f1d20800)]
>> mov [ebp-0x5],al
>>
>> while(1)
>> {
>>
>> mov ecx,0x1
>> test ecx,ecx
>> je mediaxImx!WorkerThreadFn+0x298 (f1d20748)
>>
>> DidWork = FALSE;
>>
>> mov dword ptr [ebp-0x10],0x0
>>
>> for (NextToCheck = 0; NextToCheck < MAX_WORKER_STREAMS;
>> NextToCheck++)
>> {
>>
>> mov dword ptr [ebp-0x4],0x0
>> jmp mediaxImx!WorkerThreadFn+0xed (f1d2059d)
>> mov edx,[ebp-0x4]
>> add edx,0x1
>> mov [ebp-0x4],edx
>> cmp dword ptr [ebp-0x4],0x8
>> jnb mediaxImx!WorkerThreadFn+0x203 (f1d206b3)
>>
>> <…more code here…>
>>
>> mov eax,[ebp-0x4]
>> imul eax,eax,0x28
>> mov ecx,[ebp-0xc]
>> lea edx,[ecx+eax+0xc]
>> mov [ebp-0x14],edx</smtp:xxxxx>