Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 9 April 2018

Writing WDF Drivers I: Core Concepts, Manchester, NH, 7 May 2018

Kernel Debugging & Crash Analysis for Windows, Manchester, NH, 21 May 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 23  
12 Apr 18 13:20
Igor Sharovar
xxxxxx@hotmail.com
Join Date: 01 Mar 2006
Posts To This List: 614
Maximum number of allocated Spin locks

Hello, Is there any limit to allocate spin locks? Theoretically, should be not because it is just a memory and InitializeSpinLock doesn't return any error code. However, I worry about NO_SPIN_LOCK_AVAILABLE (1D) BSOD. I could not find any documentation on this error code except the statement "This bug check appears very infrequently" which doesn't help me much. In general, I would like to know if there is any maximum number of allocating spinlock. All drivers share system resources and it is good to know such number. Igor Sharovar
  Message 2 of 23  
12 Apr 18 14:40
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
Maximum number of allocated Spin locks

<quote> Theoretically, should be not because it is just a memory and InitializeSpinLock doesn't return any error code. </quote> Exactly correct. <quote> In general, I would like to know if there is any maximum number of allocating spinlock. </quote> There is no limit to the number of spin locks that can exist in a Windows system. I haven't checked recently, but I'm not aware of any place the NO_SPIN_LOCK_AVAILABLE bugcheck is invoked. I'll check again when I get the chance, but I suspect this was used some specific place and for some specific reason that has long been lost to time. Peter OSR @OSRDrivers
  Message 3 of 23  
12 Apr 18 14:53
Igor Sharovar
xxxxxx@hotmail.com
Join Date: 01 Mar 2006
Posts To This List: 614
Maximum number of allocated Spin locks

Thanks Peter. Igor Sharovar
  Message 4 of 23  
13 Apr 18 05:55
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
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
  Message 5 of 23  
13 Apr 18 10:59
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
Maximum number of allocated Spin locks

<quote> What about deadlock detection? </quote> 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
  Message 6 of 23  
13 Apr 18 12:58
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 926
Maximum number of allocated Spin locks

<quote> What about deadlock detection? </quote> If a processor runs for too long at elevated IRQL, a DPC_WATCHDOG_VIOLATION bugcheck should be raised. //Daniel
  Message 7 of 23  
13 Apr 18 13:40
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11894
Maximum number of allocated Spin locks

<xxxxx@resplendence.com> wrote: > > <quote> > What about deadlock detection? > </quote> > > 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.
  Message 8 of 23  
13 Apr 18 13:44
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 926
Maximum number of allocated Spin locks

<..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
  Message 9 of 23  
13 Apr 18 14:15
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

> 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
  Message 10 of 23  
13 Apr 18 14:24
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

<quote> ..none of this has anything to do with the NUMBER of spinlocks. That's the BSOD code that prompted the initial question. </quote> 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
  Message 11 of 23  
13 Apr 18 14:47
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

> 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
  Message 12 of 23  
13 Apr 18 14:58
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4085
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.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/ <...excess quoted lines suppressed...> --
  Message 13 of 23  
13 Apr 18 15:49
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
Maximum number of allocated Spin locks

<quote> I heard that this bugcheck is becoming more and more of a yet another annoying feature of newer Windows versions </quote> 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
  Message 14 of 23  
13 Apr 18 16:00
Igor Sharovar
xxxxxx@hotmail.com
Join Date: 01 Mar 2006
Posts To This List: 614
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 Anton "simply misinterpreted" the article and "mistakenly linked" bad designed drivers to new features of newer Windows. As usual. Igor Sharovar
  Message 15 of 23  
13 Apr 18 17:04
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 430
Maximum number of allocated Spin locks

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 <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 <xxxxx@lists.osr.com> 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.com<mailto:xxxxx@hotmail.com> <xxxxx@lists.osr.com<mailto: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/<https://usefulpcguide.com/17082/dpc-watchdog-violat ion/https:/usefulpcguide.com/17082/dpc-watchdog-violation/> Anton Bassov --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --- 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
  Message 16 of 23  
13 Apr 18 19:23
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

> 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
  Message 17 of 23  
13 Apr 18 19:30
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
Maximum number of allocated Spin locks

<quote> My recent experience is you MUST put DPC_WATCHDOG_VIOLATION avoidance code in some kinds of drivers. </quote> 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
  Message 18 of 23  
13 Apr 18 19:55
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

> You are hanging around with and/or listening to the wrong crowd. <ironical mode> 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... </ironical mode> > 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
  Message 19 of 23  
14 Apr 18 00:58
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 430
Maximum number of allocated Spin locks

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 <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 <xxxxx@lists.osr.com> Subject: RE:[ntdev] Maximum number of allocated Spin locks <quote> My recent experience is you MUST put DPC_WATCHDOG_VIOLATION avoidance code in some kinds of drivers. </quote> 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://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 20 of 23  
14 Apr 18 01:52
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4459
Maximum number of allocated Spin locks

<quote> 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! </quote> 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
  Message 21 of 23  
17 Apr 18 10:42
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
Maximum number of allocated Spin locks

<quote> 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. </quote> Hmmmm... I guess I wasn't aware of that, and haven't encountered it. Maybe I'm just lucky? Peter OSR @OSRDrivers
  Message 22 of 23  
17 Apr 18 11:05
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4085
Maximum number of allocated Spin locks

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 <xxxxx@lists.osr.com> wrote: > <quote> > 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. > </quote> > <...excess quoted lines suppressed...> --
  Message 23 of 23  
17 Apr 18 12:24
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 430
Maximum number of allocated Spin locks

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 <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 <xxxxx@lists.osr.com> Subject: RE:[ntdev] Maximum number of allocated Spin locks <quote> 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. </quote> 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://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 08:25.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license