Hello All,

But when i run verifier, the verifier bug checks when i call
KeWaitForSingleObject(). Im using the routine in
EvtIoInternalDeviceControl callback. Im running the driver in windows
vista.

Here is the code snippet:

LARGE_INTEGER WaitCount;
WaitCount.QuadPart = -10000 * 1000; // Time out for 1 second

status = KeWaitForSingleObject( &hEvent, Executive, KernelMode, FALSE,
&WaitCount );

Here is the bug check analysis:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.
This is
because the driver was specified in the registry as being suspect (by
the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error
codes.
Typically the code is 0x1001 (deadlock detected) and
you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 0000003b, KeWaitXxx routine is being called at DISPATCH_LEVEL or
higher.
Arg2: 00000002, current irql,
Arg3: 8c5d3998, object to wait on,
Arg4: 8c5d39d4, time out parameter.

Debugging Details:
------------------

OVERLAPPED_MODULE: Address regions for 'wanarp' and 'serial.sys'
overlap

BUGCHECK_STR: 0xc4_3b

CURRENT_IRQL: 1b

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 818d873f to 81881760


I have even tried setting the timeout with NULL parameter. I get the
same bug check.
My question is when DDK help says i can use the KeWaitXxx routine at
Dispatch level. Then why does verifier fails with the bug check?

Any help would be appreciated.

Thank You.

Regards,
James

If you read the documentation completely you will see you can only call
KeWaitForSingleObject at DISPATCH_LEVEL when your timeout is zero, i.e.
test the event but do not wait. Sorry, you cannot wait at DISPATCH_LEVEL
your design is broken.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"James" <James.Smith000@gmail.com> wrote in message
news:1182858566.706826.16320@o61g2000hsh.googlegro ups.com...

Thanks for the prompt reply.

For an alternative solution can i use the following instead of
KeWaitForSingleObject()

while(1)
{
if(KeReadStateEvent(&hEvent)) // Check if event is signalled
break;
}

I will loop until the event is signalled.
Will this solve my problem? Can i use this alternative?

Thank you.

Regards,
James

The problem is that you are spinning wasting CPU time, and on a
uni-processor you are the only thread running so who is going to signal the
event. You really need to redesign this part of your driver, to get rid of
the wait on the event at DISPATCH_LEVEL.

If the code is at DISPATCH_LEVEL becaure of a spin lock is it possible to
either replace the spin lock with a muitex, or release the spin lock safely
before waiting. If the code is due to a system callback (i.e. completion
routine, DPC, etc) consider firing a worker thread (or a thread you create
in the driver) to wait on the event instead.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"James" <James.Smith000@gmail.com> wrote in message
news:1182862346.151471.118330@o11g2000prd.googlegr oups.com...

Im using a worker thread which is initiated during driver startup.
This thread is actually responsible to signal the event.

In this scenario can i use the above snippet i provided.

Thank you.

Regards,
James

No, because the worker thread will never run on a uni-processor system, so
the event is never going to be set, and the machine will deadlock.

You need to do the wait at a lower IRQL, by either putting it in a worker
thread, or changing your locking model or both.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"James" <James.Smith000@gmail.com> wrote in message
news:1182863660.348976.51640@e16g2000pri.googlegro ups.com...

I understand putting the wait in a seperate worker thread. But i dint
get the meaning of "Changing the locking model".

can you elaborate on this statement.

Regards,
James

James,

I assume the reason you are running at DISPATCH_LEVEL is that you
either have a spinlock held, or the OS called you back at this level. If
it is a spinlock, you need to change the locking model so that you do not
attempt to hold the lock while waiting.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"James" <James.Smith000@gmail.com> wrote in message
news:1182864584.401976.71940@e16g2000pri.googlegro ups.com...

Its not exactly the usage of spinlocks. I have worker thread which
gathers and processes all the firmware commands.
So when i issue a command and wait until the command is completed. The
thread would actually signal the event. The waiting is done in most of
the dispatch routines.

Can you suggest any solution for this problem.

Regards,
James

Well most of the dispatch routines run at PASSIVE_LEVEL, the reuse of the
term by Microsoft causes a lot of confusion. So there is something in the
path that is raising IRQL to DISPATCH_LEVEL, and that is causing the
problem.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"James" <James.Smith000@gmail.com> wrote in message
news:1182866144.444021.232460@x35g2000prf.googlegr oups.com...

Well, i will trace the path and look into this issue. I ll come back
to you if i have any questions.

Thanks for your suggestion.

Regards,
James

On Jun 26, 6:49 am, James <James.Smith...@gmail.com> wrote:

NNTP-Posting-Host: 220.227.243.36

Say, are many people in India named "James Smith"?

My original thinking was no, but...

Correct.

KeWaitForSingleObject can only be called at DISPATCH_LEVEL if
WaitCount.QuadPart == 0, which means - just test the object state and return
STATUS_SUCCES (signaled) or STATUS_TIMEOUT (not signaled).

In all other cases, KeWaitForSingleObject must be called at < DISPATCH_LEVEL.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

On Jun 26, 10:13 pm, chris.aselt...@gmail.com wrote:
Tor?

On Jun 27, 6:15 am, Uv <yuvr...@gmail.com> wrote:

Nope, all of his previous posts are from the exact same IP range. Tor
would move you around from post to post.

Plus, he's trying to wait at DISPATCH_LEVEL, even after reading the
doc page on KeWaitForSingleObject(), which reeks of overseas driver
behavior.

I'm just amused (but yet slightly annoyed) that he's posting under an
American-sounding alias. What is the purpose? Who is he trying to
fool?

It's obvious from his headers (and his question) who and where he is.

Chris,

Im not trying to fool any one. And talking about the alias Its the
going name which my organization has provided.

Undoubtedly im not as expert as you in developing drivers. Im just a
middle level programmer.
But i do not think its fair on your to side to discourage people who
are interested in learning new things.

Thank You.

Regards,
James

On Jun 28, 10:55 am, James <James.Smith...@gmail.com> wrote:
James,

Learn to be polite to everyone, especially the gurus. In addition,
before you post your next question, please read
http://catb.org/~esr/faqs/smart-questions.html#asking
Then as you understand what that page was talking about, go read this
document explaining KeWaitForSingleObject:
http://www.osronline.com/DDKx/kmarch/k105_40c2.htm
The root cause of your problem has also been rehashed very politely
for you in here.
If we get frustrated at your lack of understanding, its your fault for
not understanding.
At some point, you have to stop blaming the teachers and start taking
responsibility for your ignorance.

PS: My advice (as is the case for anyone else's advice) is easily
flushable.