Re: cipe-win32-pre9 fix|
Erik Wallin <erikw,AT,sec,DOT,se>|
Sun, 27 May 2001 21:15:01 +0200|
Sorry about me being off-line for a while, I've been choked with other
assignments. I've done some code reading and looking up the docs in the DDK in
the meantime though.
"Damion K . Wilson" wrote:
> Erik, I think that I've figured out part of this situation
> The spinlocks CAN cause a speedup but not for a good reason. On
> uniprocessor machines, all the spinlocks do is raise IRQL (halting task
> switching). At the elevated IRQL, the driver doesn't have to compete with
> other threads (because it becomes the only thread). This tells me that,
> somehow, code that I thought was already executing in DISPATCH_LEVEL is
> not. However, this situation also makes things supsceptible to
> IRQL_NOT_GREATER_OR_EQUAL BSOD's when spinlocks are requested when already
> at DISPATCH_LEVEL.
That sounds sound. I can't really tell if there is any speedup. Don't think
But the machine does seem "strange" when the spinlocks are in place the way I
put them. Of course they should be moved to a more limited scope. Right now
they even protect the memory allocation which is probably a bad idea.
I haven't seen any IRQL_NOT_GREATER_OR EQUAL BSOD's. Right now I have two
problems. The service crashes - often. Sometimes it won't start at all and
keeps crashing all the time.
The driver still crashes, but more seldom. This time always with the message
cancel_state_in_completed_IRP. I haven't had time to debug it yet. Usually
these crashes appear after CIPE has been idle for a long time. Maybe it has to
do with reconnecting to the other end. Maybe there is a problem with the
service connecting to the driver especially when the service has crashed
The reason I think so is because the service keeps crashing a lot. I haven't
had time to debug that anything, but right now I'm just telling the service
manager to restart the service if it crashes. That keeps me connected, but
eventually it breaks down anyway. It seems that there are bug left both in the
driver and the service.
> In fact, there also exists the possibility that the same code sections are
> getting called at both PASSIVE_LEVEL and at DISPATCH_LEVEL, thus requiring
> that the code only elevate is IRQL when it needs to, and not all the
> Anyway, I think that, when I figure this bit out, things should clear up
> nicely. All this info has come out of chapter 7 of Windows NT Device Driver
> Development (Macmillan Technical Publishing).
The only thing I've got access to right now is the docs from the DDK.
I'll do some more testing and see if I can pinpoint any of the problems. Let
know if there is anything you want me to test.