? which is a little feature of the worker thread implementation that raises
a bugcheck if the work item routine happens to return with IRQL raised above
PASSIVE_LEVEL.
I will point you back to my original question: ?Do you release your
spinlock properly??
Because there is mounting evidence to suggest you do not with result being
that on return from your driver the KS worker thread that has just services
some sort of passive level activity entry point in your code (either
directly or indirectly) has returned with some entity having not restored
IRQL (and most likely not having released a spinlock properly or at all).
So quit dancing around RtlCopyMemory(). It is bloody memcpy, an intrinsic,
that works just fine at any IRQL so long as the memory it touches (source /
destination) are resident or can be made resident. If your problem was with
the memory accessed by RtlCopyMemory/memcpy/repmovs_ then the bugcheck for
invalid access would have been raised and the address in the bugcheck data
would be pointing your right at your driver and the buffer you were
RtlCopyMemory() to/from.
Go find the lock you don?t release correctly. If you want the debugger to
land in your code and point you right at the problem then get in the habit
of adding code like this to the entry/exit of callback routines that have a
call contract of IRLQ < DISPATCH_LEVEL
VOID
MyClass::MyVirtualFunctionThatIsCalledByPortClsAtPassiveLevel()
{
#if DBG
KIRQL dbgEntryIrql = KeGetCurrentIrql();
#endif
ASSERT(dbgEntryIrql < DISPATCH_LEVEL);
… do your stuff including forgetting to restore IRQL
ASSERT(KeGetCurrentIrql() == dbgEntryIrql);
}
Heck, since you are writing a KS/PortCls driver you event get to hang
yourself with C++. Write a simple class that does the check automatically
no matter ?how? you exit the function (think CTOR capture IRQL, DTOR test on
exit). The class can compile to nothing in the free build.
Instead of flailing about in the debugger, write code that checks itself in
the debug version. If you have a call entry/exit contract from an external
component (this is usually overkill to validate entry/exit contracts on all
of your functions in your driver)
?This function is called at PASSIVE_LEVEL?
Or
?This function is called at IRQL < DISPATCH_LEVEL?
Or
?This function is called at DISPATCH_LEVEL?
Then test and ASSERT() that contract is maintained. That way, you catch
*your* bugs while still in the code that is about to cause the BSOD and you
catch *the other guys bug* before you go do all the damage and get blamed
for it.
Good Luck,
Dave Cattley
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sivakumar thulasimani
Sent: Thursday, August 06, 2009 2:24 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] D1, {b5388508, 2, b5388508, 88dafb2c} what is the 3rd
parameter???
Hi karthik,
I have no idea on how to use Kernel Streaming but you have said that
your driver uses Kernel streaming, so i think that there must be some
paramters or data that you have to transfer to it. Based on the !analyze -v
output my interpretation is as follows ( hoping the more exprienced will
correct me if i am wrong )
STACK_TEXT:
ba50bd54 b5306452 0000000a b531d508 00000002 nt!KeBugCheckEx+0x1b
ba50bd7c 8053877d 87a3ed98 00000000 8a23fda8 ks!WorkerThread+0x70
Now the address “b531d508” i think is within the KS module. In Xp code this
is what i see for Ks!workerthread
f6b537ee ff1510b0b5f6 call dword ptr [ks!_imp__KeGetCurrentIrql
(f6b5b010)]
f6b537f4 84c0 test al,al
f6b537f6 0f853d0c0000 jne ks!WorkerThread+0x4f (f6b54439)
ks!WorkerThread+0x4f:
f6b54439 56 push esi
f6b5443a ff7608 push dword ptr [esi+8]
f6b5443d ff1510b0b5f6 call dword ptr [ks!_imp__KeGetCurrentIrql
(f6b5b010)]
f6b54443 0fb6c0 movzx eax,al
f6b54446 50 push eax
f6b54447 ff7608 push dword ptr [esi+8]
f6b5444a 6a0a push 0Ah
f6b5444c ff15e4b0b5f6 call dword ptr [ks!_imp__KeBugCheckEx (f6b5b0e4)]
Which seems that the worker thread intentionally checks the IRQL and
preforms a bugcheck if it is anything greater than passive level. So Why it
performs the check you have to find out ;).
-rtshiva
On Thu, Aug 6, 2009 at 11:07 AM, Karthik Gurumurthy
wrote:
shiva,
The peculiar thing here is i am not using any workitems its just an
copy operation, its an virtual wavepci audio driver i am copying mapped data
into me buffer, this crash is not frequent all things render and capture
operation will go on smoothly but some time out of blue this BSOD comes up.
My driver is NXTBT.sys but in analyze report their is no trace of this
driver!!.
Karthik SG
On Thu, Aug 6, 2009 at 10:56 AM, sivakumar thulasimani
wrote:
Hi karthik,
It was just a guess that RtlCopyMemory could have caused it,
So keep your options open still :). Hmm… as for how to see if memory is
resided or not , is the target and the destination memory location allocated
in non paged memory or is it in stack ? . Also check the parameters you are
passing to the KS workitem. are they valid ? just another guess is are you
supposed to send the spinlock also to this workitem and is this spinlock in
stack?
-rtshiva
On Thu, Aug 6, 2009 at 10:39 AM, Karthik Gurumurthy
wrote:
Hi Shiva,
RtlcopyMemory is called while lock is on and it is non-paged (i
tought that both from and to memory are resident) but it seems they are not.
Do you know how to find both the memory is resident or not.
Karthik SG
On Thu, Aug 6, 2009 at 10:34 AM, sivakumar thulasimani
wrote:
Hi karthik,
Are you calling RtlCopyMemory after you release the spinlock or
while the spinlock is still held ? as holding a spinlock raises the IRQL to
dispatch level and the documentation for RtlCopyMemory clearly states that
you can call it only when the caller’s IRQL <= APC Level.
-rtshiva
On Thu, Aug 6, 2009 at 10:02 AM, Karthik Gurumurthy
wrote:
hi,
After fixing all the symbols the analyze result is
********************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: b531d508, memory referenced
Arg2: 00000002, IRQL
Arg3: b531d508, value 0 = read operation, 1 = write operation
Arg4: 879cd664, address which referenced memory
Debugging Details:
------------------
WORKER_ROUTINE:
ks!KsWorkSinkItemWorker+0
b531d508 8bff mov edi,edi
WORK_ITEM: 879cd664
CURRENT_IRQL: 2
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from b5306452 to 804f9f43
STACK_TEXT:
ba50bd54 b5306452 0000000a b531d508 00000002 nt!KeBugCheckEx+0x1b
ba50bd7c 8053877d 87a3ed98 00000000 8a23fda8 ks!WorkerThread+0x70
ba50bdac 805cff70 87a3ed98 00000000 00000000 nt!ExpWorkerThread+0xef
ba50bddc 805460ee 8053868e 00000002 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
ks!WorkerThread+70
b5306452 ff1520d030b5 call dword ptr [ks!_imp_KfReleaseSpinLock
(b530d020)]
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: ks!WorkerThread+70
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ks
IMAGE_NAME: ks.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 48025c12
FAILURE_BUCKET_ID: 0xD1_ks!WorkerThread+70
BUCKET_ID: 0xD1_ks!WorkerThread+70
Followup: MachineOwner
---------
**************************************
Karthik SG
On Thu, Aug 6, 2009 at 1:34 AM, Maxim S. Shatskih
wrote:
> as you said both memory are likely to be non-recsident (what is
the best way to identify that???)
>and since IRQL is at DPC how can i do RtlCopyMemory here, do i need to
reduce the IRQL then after
No, you cannot call KeLowerIrql arbitrary, you can do this only if you
called KeRaiseIrql yourself before.
You just cannot touch pageable memory at >= DISPATCH, redesign your code to
make this memory nonpaged.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com http:</http:>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
