Maximum number of allocated Spin locks

> 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…

Anton Bassov

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.”

Peter
OSR
@OSRDrivers

If a processor runs for too long at elevated IRQL, a DPC_WATCHDOG_VIOLATION
bugcheck should be raised.

//Daniel

wrote:
>
>


>
> If a processor runs for too long at elevated IRQL, a
> DPC_WATCHDOG_VIOLATION bugcheck should be raised.

Yes, but none of this has anything to do with the NUMBER of spinlocks.Â
That’s the BSOD code that prompted the initial question.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

…none of this has anything to do with the NUMBER of spinlocks. That’s the
BSOD code that prompted the initial question.>

Thanks, but we knew that Tim. We found it worth mentioning anyway.

Regards,

//Daniel

> The system hangs when there’s a deadlock.

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.

Anton Bassov

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…

Anton Bassov

> 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

https://usefulpcguide.com/17082/dpc-watchdog-violation/https://usefulpcguide.com/17082/dpc-watchdog-violation/

Anton Bassov

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.com <
xxxxx@lists.osr.com> 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

https://usefulpcguide.com/17082/dpc-watchdog-violation/
https://usefulpcguide.com/17082/dpc-watchdog-violation/

Anton Bassov


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&gt;
></http:></http:>

You are hanging around with and/or listening to the wrong crowd.

This is not a problem on well-configured Windows systems, running properly written drivers.

Peter
OSR
@OSRDrivers

>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

https://usefulpcguide.com/17082/dpc-watchdog-violation/https://usefulpcguide.com/17082/dpc-watchdog-violation/https:</https:>

Anton Bassov


NTDEV is sponsored by OSR

Visit the list online at: http:

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…

Anton Bassov

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!

Peter
OSR
@OSRDrivers

> 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…

Anton Bassov

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!

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

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:</http:></http:></http:>

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

Anton Bassov

Hmmmm… I guess I wasn’t aware of that, and haven’t encountered it. Maybe I’m just lucky?

Peter
OSR
@OSRDrivers

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&gt;
></http:></http:>

The article at https://blogs.msdn.microsoft.com/ntdebugging/2012/12/07/determining-the-source-of-bug-check-0x133-dpc_watchdog_violation-errors-on-windows-server-2012/ talks about both timeouts.

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?

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

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:</http:></http:></http:>