@Peter_Viscarola said:
I suppose a follow-up question would be why the old driver is stuck
Since you’re giving us exactly no information on which to base our opinions… I’ll take a guess: There’s something that has a handle open to one of the driver’s Device Objects??
I know this is a vague follow-up question. Truth is I’m still just figuring out the way WDF works (and Windows drivers in general), which is why I don’t know which information is relevant to you. You can consider this issue closed if you want, as the main bug I came for is fixed (or at least figured out). Regardless, as for the handle, could such a handle remain open through a restart of the machine? I’m going to go through the driver stores and symbolic links to manually remove it, but I’ll still need to figure it what caused this in the first place.
As a complete aside:
Also, Mr. Synthwave, please do not cross-post. From the Community Guidelines that I’m sure you read before posting, as we ask:
PLEASE DO NOT POST THE SAME QUESTION TO IN MULTIPLE CATEGORIES. Also, please do the Community members the courtesy of searching the archives before you post a question.
(your post to NTFSD has been deleted)
Yeah I know, sorry. I tried to delete my post in NTFSD (it’s not a file systems post) but there is no such functionality. I reported it for deletion and posted here. My bad!
@anton_bassov said:
Well, it depends…
On one hand, the very fact that the OP uses KeDelayExecutionThread() somehow suggests that KeStallExecutionProcessor() is hardly a good option here. The thing is, the shortest delay that that KeDelayExecutionThread() may possibly achieve is measured in clock ticks, and, hence, is just HUGE by KeStallExecutionProcessor()'s standards. In fact, the time interval that KeDelayExecutionThread() 's code in itself runs before/after the thread actually goes blocking is, probably, a bit too large by KeStallExecutionProcessor()'s standards anyway. Therefore, KeStallExecutionProcessor() does not really seem to be an ideal option here, at least not at the first glance.
OTOH, a bit of extra unnecessary spinning at low IRQL, no matter how unreasonable it may seem to be at the first glance, is not really going to do you any more or less tangible harm, at least not if it happens sporadically once in a while. Assuming that it happens in context of an “ordinary” thread, the worst thing that may happen here is that the target thread simply uses up its quantum in a pointless spinning loop and gets subsequently preempted. By the time it gets scheduled on the CPU again, the requested delay is more than likely to have had already expired. Therefore, unless this “unreasonable” code executes over and over again, this option seems to be not that bad…
Anton Bassov
I’m still playing around with the delay, and if it’s short enough I’ll try using KeStallExecutionProcessor(). Oh, and I don’t plan on actually keeping a three-second delay, don’t worry. It was just to prove that the delay indeed wasn’t working. The actual delay is shorter. I’ll still need to play around with that.