> I suspect this was used some specific place and for some specific reason that has
long been lost to time.
What about deadlock detection?
Judging from the existing API, this bugcheck may be encountered only upon spinlock acquisition attempt. After all, if the system detects a deadlock at elevated IRQL bugchecking seems to be, probably, not the worst out of all options available. How could it be done? For example, you could count the number of inner loop iterations upon spinlock acquisition, and assume a deadlock if it reaches some reasonably high limit…
What about it? The system hangs when there’s a deadlock.
The CHECKED BUILD of Windows will detect attempt to recursively acquire a spin lock… but beyond that, and the locking hierarchy validation that Driver Verifier provides, I’m not aware of any deadlock detection beyond the obvious “your system has stopped working.”
Sure, but it is not necessarily going to happen straight away, at least on a MP system. As long as a given core/thread does not try to acquire the target spinlock it is going to be just fine. If the lock in question is not really in a high demand and the number of logical CPUs is reasonably high it may take quite a while before all of them are taken out of play and the system becomes unresponsive. Therefore, there is a possibility (at least a theoretical one) that a corrupted system keeps on running long enough for causing a persistent damage to itself.
Actually, my point is that the OP could have simply misinterpreted NO_SPIN_LOCK_AVAILABLE code and mistakenly linked it to a maximal number of spinlocks at the time when, in actuality, it bears no relation to this (non-existent) number whatsoever. It never occurred to you to think this way, did it…
> If a processor runs for too long at elevated IRQL, a DPC_WATCHDOG_VIOLATION
bugcheck should be raised.
I heard that this bugcheck is becoming more and more of a yet another annoying feature of newer Windows versions that users are forced to find a way around
> If a processor runs for too long at elevated IRQL, a
DPC_WATCHDOG_VIOLATION
>bugcheck should be raised.
I heard that this bugcheck is becoming more and more of a yet another
annoying feature of newer Windows versions that users are forced to find a
way around
Visit the list online at: http:> showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:></http:>
>hmmm… I run a shit-tonne of w10 systems, vms, hardware, servers/desktops and I have zero >DPC_WATCHDOG_VIOLATION crashes.
Mark Roddy
Anton “simply misinterpreted” the article and “mistakenly linked” bad designed drivers to new features of newer Windows. As usual.
Igor Sharovar
My recent experience is you MUST put DPC_WATCHDOG_VIOLATION avoidance code in some kinds of drivers. High speed devices that receive unsolicited data (like NICs) don’t have much control over that incoming data, and if the incoming data rate exceeds the available cpu cycles to process in your DPC, you will violate the DPC watchdog limits. Avoidance strategies would include dynamically shifting work from a DPC to a worker thread, or causing hardware/protocol flow control to reduce the data rate, or discarding incoming data that’s monopolizing the cpu. Devices that only process solicited responses, tend to be much more self-regulating because new request don’t happen if lots of cpu time is consumed by completion DPCs.
I’ve also seen the DPC watchdog trigger on storage stacks under the following conditions: your storage request rate exceeds your I/O processing request rate, and the queue of storage requests grows too big. I’ve seen the logging writes for SQLServer trigger this, when 45K writes were pending. Some components of the storage stack degrade in performance as the number of outstanding requests grows, and as performance degrades the queue grows faster. I assume there is some exponential curve that describes things just before crashing. It gets ugly if the storage completion performance degrades when there are a lot of outstanding requests, as this path is called during the Storport request completion DPC. A correctly functioning storage miniport can be the victim of this condition. Those of you writing filter drivers for the storage stack should understand how your completion performance is impacted by large pending queues.
Jan
From: xxxxx@lists.osr.com On Behalf Of xxxxx@gmail.com Sent: Friday, April 13, 2018 11:58 AM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Maximum number of allocated Spin locks
hmmm… I run a shit-tonne of w10 systems, vms, hardware, servers/desktops and I have zero DPC_WATCHDOG_VIOLATION crashes.
Mark Roddy
On Fri, Apr 13, 2018 at 2:46 PM, xxxxx@hotmail.commailto:xxxxx > wrote: > If a processor runs for too long at elevated IRQL, a DPC_WATCHDOG_VIOLATION >bugcheck should be raised.
I heard that this bugcheck is becoming more and more of a yet another annoying feature of newer Windows versions that users are forced to find a way around
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx>
> Anton “simply misinterpreted” the article and “mistakenly linked” bad designed
drivers to new features of newer Windows. As usual.
OMG…
Looks like I made yet another enemy out of the blue. I did not mean to hurt yo in any possible way.
You seem to be a way to touchy, at least on my books. OTOH, these days it seems to be just sort of “fashionable” to be offended with just about anything that one may possibly imagine, so that I should have taken it into the account. My apologies…
You need to put DPC monopolization avoidance code in your properly written driver. If the DPC watchdog ferrets out your evil ?I spend too long in my DPC? cases, then it?s doing it?s job!
My favorite way of doing this is to limit the processing in my DPC some way (numbers of received messages, for example, or numbers of buffers or requests processed) and if I still have work to do… queue a DPC back to have my DpcForIsr run again.
Keeps the system responsive and avoids the dreaded consequences of doing the wrong thing!
> You are hanging around with and/or listening to the wrong crowd.
Oh dear…
Actually, the way you put it reminds me of “PUBLISH YOUR NAME…(etc)” folks, as well as of “JUST SAY NO” ones. In fact, I suspect a significant overlap between these two camps, but this is already a different story…
This is not a problem on well-configured Windows systems, running properly written drivers.
The way I understand it, the target reader of above mentioned article is an average Joe who
has brought a brand-new OEM PC or laptop right from the store (or,alternatively, plugged in a newly-purchased peripheral), and expects everything “just to work”, rather than “well-configuring” his new system, let alone searching for “properly written drivers”.
Judging from the way this article puts it (as well as from the very fact that someone bothered to write it ,in the first place), the situation when the actual reality differs from above mentioned idealistic scenario that average Joe expects is far from being exceptional…
I’m puzzled how queueing another DPC fully resolves the DPC watchdog timeout. There are TWO watchdog timers, one limit for an individual DPC, and another for back-to-back DPCs. To avoid this second DPC watchdog bugcheck you must give up the CPU to passive_level for a few moments.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@osr.com Sent: Friday, April 13, 2018 4:30 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Maximum number of allocated Spin locks
Yes! And, ahhh, no!
You need to put DPC monopolization avoidance code in your properly written driver. If the DPC watchdog ferrets out your evil ?I spend too long in my DPC? cases, then it?s doing it?s job!
My favorite way of doing this is to limit the processing in my DPC some way (numbers of received messages, for example, or numbers of buffers or requests processed) and if I still have work to do… queue a DPC back to have my DpcForIsr run again.
Keeps the system responsive and avoids the dreaded consequences of doing the wrong thing!
IIRC, there was a thread on NTDEV around 12 or so years ago, complaining about
Starforce ( or whatever it is called) game protection scheme. According to the complaint, this is EXACTLY what it was doing - its DPC was re-queuing itself yo the head of the queue over and over again, effectively making the system totally unresponsive for dozens of seconds.
This was the purpose of the whole exercise - by making the system unresponsive it was expecting to prevent unauthorised copying. After all, you cannot really copy things if your system’s both GUI and command line are unavailable, can you.
However,once it did not spend more than 100us in a DPC routine it could easily make its way around certification requirements. However,it was back in the days of XP, so that DPC_WATCHDOG_VIOLATION was not anywhere in sight at the time.
I just wonder how it would work with more recent OS versions. Judging from what you say, it would not pose any problem whatsoever, at least not in terms of DPC_WATCHDOG_VIOLATION
If you are using a high importance dpc object for your requeue, that would
be the wrong thing to do. If you aren’t and you really are running into
this problem, then you could set the cpu for the other dpc to be ‘not this
cpu’.
Mark Roddy
On Tue, Apr 17, 2018 at 10:41 AM, xxxxx@osr.com wrote:
>
> > Hmmmm… I guess I wasn’t aware of that, and haven’t encountered it. > Maybe I’m just lucky? > > Peter > OSR > @OSRDrivers > > > — > NTDEV is sponsored by OSR > > Visit the list online at: http:> showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:></http:>
The API KeQueryDpcWatchdogInformation returns the current and limit values for both timers.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@osr.com Sent: Tuesday, April 17, 2018 7:42 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Maximum number of allocated Spin locks
Hmmmm… I guess I wasn’t aware of that, and haven’t encountered it. Maybe I’m just lucky?