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, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 36  
29 Sep 08 14:38
Aydan Yumerefendi
xxxxxx@gmail.com
Join Date: 26 Aug 2008
Posts To This List: 31
Skipping IRP stack locations and driver verifier problems

I have a TDI filter driver, which does not need to process all IRPs that it receives. For the IRPs that I do not want to filter I use the following code in my dispatch function: IoSkipCurrentIrpStackLocation(pIrp); status = IoCallDriver(pDeviceExtension->pLowerDeviceObject, pIrp); return status; If the driver verifier is disabled, this works just fine. Enabling the driver verifier and I/O verification, causes an error: WDM DRIVER ERROR: This IRP is about to run out of stack locations Note that the error occurs on Server 2003 (both x86 and x64). It does not happen on XP x32. This warning happens only for IRPs that have insufficient stack location (pIrp->CurrentLocation=1). Here is the callstack before calling the filtered driver mydriver!MyDeviceExtensionDispatchInternal+0x10b mydriver!MyDispatchInternal+0x73 nt!IovCallDriver+0x1b5 netbt!NbtDpcPostIrpToProvider+0x7e nt!KiRetireDpcList+0x150 nt!KiDispatchInterrupt+0x4f At that time: pIrp->StackCount = 2 and pIrp->CurrentLocation = 1 After calling IoSkipCurrentIrpStackLocation, pIrpCurrentLocation is 2 (as expected), and pIrp->Tail.Overlay.CurrentStackLocation has changed. I have several questions: - Is this the right way to pass IRPs that I do not want to have a completion routine for down to the lower driver? - Is the driver verifier correct is pointing a problem or this is a false positive? Is the verifier confused by the use of IoSkipCurrentIrpStackLocation and if so, is there a way to get by this problem? Thank you in advance, --aydan
  Message 2 of 36  
29 Sep 08 16:50
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2105
Skipping IRP stack locations and driver verifier problems

I saw similar issues with a TDI filter and eventually concluded that it was a verifier 'failure' to correctly measure what is going on. The issue is that somehow the stack got an IRP without out enough stack locations for each driver in the stack. Since your driver is the first one with verifier enabled (who knows, maybe it is the top of the stack, but no matter) it is the first chance verifier has to complain about it. TDI filtering in particular is so full of bad actors, hacks, and other ugliness, verifier can hardly be expected to guess if an IRP might actually succeed. However, I agree with your observation that in this case, verifier does have enough information to know that the particular IRP *does* have enough remaining stack locations to traverse the remainder of the device stack. I found that using I/O verification in a TDI (filter) stack was very much a hassle. Let's face it, a TDI filter has to be explicitly aware of IRP stack exhaustion and the 'rules' get seriously bent to make it all work period. Given that landscape, it is better for you to have direct instrumentation (ASSERT()s, etc.) in your code to catch these errors instead of using verifier to do it for you. Let's face it. Your driver *does* have all the information to know when to bugcheck! Good luck, Dave Cattley Consulting Engineer Systems Software Devlopment -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com Sent: Monday, September 29, 2008 2:38 PM To: Windows System Software Devs Interest List Subject: [ntdev] Skipping IRP stack locations and driver verifier problems I have a TDI filter driver, which does not need to process all IRPs that it receives. For the IRPs that I do not want to filter I use the following code in my dispatch function: IoSkipCurrentIrpStackLocation(pIrp); status = IoCallDriver(pDeviceExtension->pLowerDeviceObject, pIrp); return status; If the driver verifier is disabled, this works just fine. Enabling the driver verifier and I/O verification, causes an error: WDM DRIVER ERROR: This IRP is about to run out of stack locations Note that the error occurs on Server 2003 (both x86 and x64). It does not happen on XP x32. This warning happens only for IRPs that have insufficient stack location (pIrp->CurrentLocation=1). Here is the callstack before calling the filtered driver mydriver!MyDeviceExtensionDispatchInternal+0x10b mydriver!MyDispatchInternal+0x73 nt!IovCallDriver+0x1b5 netbt!NbtDpcPostIrpToProvider+0x7e nt!KiRetireDpcList+0x150 nt!KiDispatchInterrupt+0x4f At that time: pIrp->StackCount = 2 and pIrp->CurrentLocation = 1 After calling IoSkipCurrentIrpStackLocation, pIrpCurrentLocation is 2 (as expected), and pIrp->Tail.Overlay.CurrentStackLocation has changed. I have several questions: - Is this the right way to pass IRPs that I do not want to have a completion routine for down to the lower driver? - Is the driver verifier correct is pointing a problem or this is a false positive? Is the verifier confused by the use of IoSkipCurrentIrpStackLocation and if so, is there a way to get by this problem? Thank you in advance, --aydan --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: 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 3 of 36  
01 Oct 08 15:30
Aydan Yumerefendi
xxxxxx@gmail.com
Join Date: 26 Aug 2008
Posts To This List: 31
Skipping IRP stack locations and driver verifier problems

Dave, Thank you for the reply. I guess we will disable IO verification and add asserts to our code instead. Thanks, --aydan
  Message 4 of 36  
01 Oct 08 15:34
Bill McKenzie
xxxxxx@sbcglobal.net
Join Date:
Posts To This List: 236
Skipping IRP stack locations and driver verifier problems

It sure would be nice if we had a constant, consistent and attentive avenue for reporting this kind of stuff. As it is, I wouldn't even try...I find error reporting to Microsoft an exercise in futility. Not the end of the world, but it would be nice. Bill M. "David R. Cattley" <xxxxx@msn.com> wrote in message news:112145@ntdev... >I saw similar issues with a TDI filter and eventually concluded that it was > a verifier 'failure' to correctly measure what is going on. > > The issue is that somehow the stack got an IRP without out enough stack > locations for each driver in the stack. Since your driver is the first > one > with verifier enabled (who knows, maybe it is the top of the stack, but no > matter) it is the first chance verifier has to complain about it. > > TDI filtering in particular is so full of bad actors, hacks, and other <...excess quoted lines suppressed...>
  Message 5 of 36  
01 Oct 08 15:59
Ken Johnson
xxxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 1022
Skipping IRP stack locations and driver verifier problems

<rant> Agree. I had a complex deadlock with smart card removal on an integrated (= but internally USB attached) smart card reader that manifested itself acros= s a suspend/resume in Vista x64 RTM that crossed user mode (about 4 differe= nt service processes) and kernel mode (PnP) that ultimately was caused by M= S code calling LoadLibrary in DllMain (totally no-brainer stupid bug), subs= equently stalling things in a PnP service notification via a concoluted cha= in of RPC calls. I spent about 12 hours of my own time in kd on my own personal box triaging= the issue, then I tried to report it to get fixed using one of my (at the = time) MVP support incidents. This was a total flop, even through the MVP channel (which, I assume, likel= y has a much higher chance of getting somewhere than your average small bus= iness PSS incident). Despite having debugged the *whole damned problem*, a= nd having shown that it resulted from a bad practice that MSDN explicitly c= alled out, I could not, for the life of me, get PSS to do anything more tha= n acknowledge that the DllMain thing might be a bug and might get entered i= n a bug database for a future Windows major release. (Of course, they could not follow up if this ever did actually happen.) Fast forward 12 months, and a QFE hotfix is released that fixes the exact p= roblem, (presumably because a large enough customer complained). Ugh. Aft= er PSS explicitly told me that there was no way that I could hope for anyth= ing other than a bug *maybe* being created for a future Windows release. That sort of thing totally burns me up about reporting issues to Microsoft = externally; unless you either 1) know the owner of the component and can ge= t ahold of them directly, or 2) are a megacorp, you get the complete run-ar= ound and things don't get fixed, at least not until someone sufficiently im= portant complains. </rant> If you know someone on the inside on the team that owns the broken componen= t, then things are great, but the barrier of getting anything to said team = from the outside world is just incredibly, ridiculously painful if you don'= t have someone's direct email to report stuff via unofficial channels. - S -----Original Message----- From: Bill McKenzie <xxxxx@sbcglobal.net> Sent: Wednesday, October 01, 2008 14:37 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: Re:[ntdev] Skipping IRP stack locations and driver verifier proble= ms It sure would be nice if we had a constant, consistent and attentive avenue for reporting this kind of stuff. As it is, I wouldn't even try...I find error reporting to Microsoft an exercise in futility. Not the end of the world, but it would be nice. Bill M. "David R. Cattley" <xxxxx@msn.com> wrote in message news:112145@ntdev... >I saw similar issues with a TDI filter and eventually concluded that it wa= s > a verifier 'failure' to correctly measure what is going on. > > The issue is that somehow the stack got an IRP without out enough stack > locations for each driver in the stack. Since your driver is the first > one > with verifier enabled (who knows, maybe it is the top of the stack, but n= o > matter) it is the first chance verifier has to complain about it. > > TDI filtering in particular is so full of bad actors, hacks, and other > ugliness, verifier can hardly be expected to guess if an IRP might > actually > succeed. However, I agree with your observation that in this case, > verifier > does have enough information to know that the particular IRP *does* have > enough remaining stack locations to traverse the remainder of the device > stack. <...excess quoted lines suppressed...> s > > I have a TDI filter driver, which does not need to process all IRPs that > it > receives. For the IRPs that I do not want to filter I use the following > code > in my dispatch function: > > IoSkipCurrentIrpStackLocation(pIrp); > status =3D IoCallDriver(pDeviceExtension->pLowerDeviceObject, pIrp); > return status; --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.o= sronline.com/page.cfm?name=3DListServer
  Message 6 of 36  
01 Oct 08 16:07
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1612
Skipping IRP stack locations and driver verifier problems

> -----Original Message----- > From: xxxxx@lists.osr.com=20 > [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie > Sent: Wednesday, October 01, 2008 9:36 PM > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] Skipping IRP stack locations and driver=20 > verifier problems >=20 > It sure would be nice if we had a constant, consistent and=20 > attentive avenue=20 <...excess quoted lines suppressed...> It isn't sooo bad. In the past and this year I was able to obtain several hotfixes for our USB problems. Well, it took months (because there is so many bugs in Vista :). For WDK docs feedback I receive "will be fixed" replies within few days. It isn't completely futile but could be definitely better. It'd be nice if for development tools is there something similar as WDK docs feedback. Maybe another link on the utility description page in docs? Best regards, Michal Vodicka UPEK, Inc. [xxxxx@upek.com, http://www.upek.com]=20
  Message 7 of 36  
01 Oct 08 16:08
Ken Johnson
xxxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 1022
Skipping IRP stack locations and driver verifier problems

Actually, it may have been an RPC call out of DllMain and not just LoadLibr= ary (in case anyone here actually looked at this bug), but it was egregriou= sly bad in any case. </self response> - S -----Original Message----- From: Skywing <xxxxx@valhallalegends.com> Sent: Wednesday, October 01, 2008 15:01 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: RE: Re:[ntdev] Skipping IRP stack locations and driver verifier pr= oblems <rant> Agree. I had a complex deadlock with smart card removal on an integrated (= but internally USB attached) smart card reader that manifested itself acros= s a suspend/resume in Vista x64 RTM that crossed user mode (about 4 differe= nt service processes) and kernel mode (PnP) that ultimately was caused by M= S code calling LoadLibrary in DllMain (totally no-brainer stupid bug), subs= equently stalling things in a PnP service notification via a concoluted cha= in of RPC calls. I spent about 12 hours of my own time in kd on my own personal box triaging= the issue, then I tried to report it to get fixed using one of my (at the = time) MVP support incidents. This was a total flop, even through the MVP channel (which, I assume, likel= y has a much higher chance of getting somewhere than your average small bus= iness PSS incident). Despite having debugged the *whole damned problem*, a= nd having shown that it resulted from a bad practice that MSDN explicitly c= alled out, I could not, for the life of me, get PSS to do anything more tha= n acknowledge that the DllMain thing might be a bug and might get entered i= n a bug database for a future Windows major release. (Of course, they could not follow up if this ever did actually happen.) Fast forward 12 months, and a QFE hotfix is released that fixes the exact p= roblem, (presumably because a large enough customer complained). Ugh. Aft= er PSS explicitly told me that there was no way that I could hope for anyth= ing other than a bug *maybe* being created for a future Windows release. That sort of thing totally burns me up about reporting issues to Microsoft = externally; unless you either 1) know the owner of the component and can ge= t ahold of them directly, or 2) are a megacorp, you get the complete run-ar= ound and things don't get fixed, at least not until someone sufficiently im= portant complains. </rant> If you know someone on the inside on the team that owns the broken componen= t, then things are great, but the barrier of getting anything to said team = from the outside world is just incredibly, ridiculously painful if you don'= t have someone's direct email to report stuff via unofficial channels. - S -----Original Message----- From: Bill McKenzie <xxxxx@sbcglobal.net> Sent: Wednesday, October 01, 2008 14:37 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: Re:[ntdev] Skipping IRP stack locations and driver verifier proble= ms It sure would be nice if we had a constant, consistent and attentive avenue for reporting this kind of stuff. As it is, I wouldn't even try...I find error reporting to Microsoft an exercise in futility. Not the end of the world, but it would be nice. Bill M. "David R. Cattley" <xxxxx@msn.com> wrote in message news:112145@ntdev... >I saw similar issues with a TDI filter and eventually concluded that it wa= s > a verifier 'failure' to correctly measure what is going on. > > The issue is that somehow the stack got an IRP without out enough stack > locations for each driver in the stack. Since your driver is the first > one > with verifier enabled (who knows, maybe it is the top of the stack, but n= o > matter) it is the first chance verifier has to complain about it. > > TDI filtering in particular is so full of bad actors, hacks, and other > ugliness, verifier can hardly be expected to guess if an IRP might > actually > succeed. However, I agree with your observation that in this case, > verifier > does have enough information to know that the particular IRP *does* have > enough remaining stack locations to traverse the remainder of the device > stack. <...excess quoted lines suppressed...> s > > I have a TDI filter driver, which does not need to process all IRPs that > it > receives. For the IRPs that I do not want to filter I use the following > code > in my dispatch function: > > IoSkipCurrentIrpStackLocation(pIrp); > status =3D IoCallDriver(pDeviceExtension->pLowerDeviceObject, pIrp); > return status; --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.o= sronline.com/page.cfm?name=3DListServer --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.o= sronline.com/page.cfm?name=3DListServer
  Message 8 of 36  
01 Oct 08 16:14
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1612
Skipping IRP stack locations and driver verifier problems

> -----Original Message----- > From: xxxxx@lists.osr.com=20 > [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing > Sent: Wednesday, October 01, 2008 9:59 PM > To: Windows System Software Devs Interest List > Subject: RE: Re:[ntdev] Skipping IRP stack locations and=20 > driver verifier problems >=20 > That sort of thing totally burns me up about reporting issues=20 > to Microsoft externally; unless you either 1) know the owner=20 <...excess quoted lines suppressed...> 3) megacorps are your customers. When a support incident is successfully (bug admitted) finished, I fill impact info which influences the decision when the problem will be fixed (hotfix, next SP, next OS version). Well, I report only BSODs and when I'm sure about OS bug. For our it usually takes months but some our customers can have QFE within a few days. Best regards, Michal Vodicka UPEK, Inc. [xxxxx@upek.com, http://www.upek.com]=20
  Message 9 of 36  
01 Oct 08 17:22
Calvin Guan
xxxxxx@yahoo.ca
Join Date: 15 May 2005
Posts To This List: 308
Skipping IRP stack locations and driver verifier problems

> 3) megacorps are your customers. Depends how many millions pieces of hardware you sell per quarter. I worked for companies sell a lot and some other sell very few. For the former, I wouldn't have to worry about os bugs as long as I have convinced both msft and customers. It will get fixed sooner or later depending on how bad the problem is and how many millions of units are being affected. Tier one oems can do very good job here but they will always kick little guys butt first before they go to microsoft. For the latter, yes I feel the pain. Calvin __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com
  Message 10 of 36  
01 Oct 08 17:41
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1612
Skipping IRP stack locations and driver verifier problems

> -----Original Message----- > From: xxxxx@lists.osr.com=20 > [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan > Sent: Wednesday, October 01, 2008 11:22 PM > To: Windows System Software Devs Interest List > Subject: RE: Re:[ntdev] Skipping IRP stack locations and=20 > driver verifier problems >=20 > For the former, I wouldn't have to worry about os bugs as=20 > long as I have convinced both msft and customers.=20 The second can be a problem. Some customers tend to say "the problem doesn't occur without your device so it is you who have to solve it". Even when MS confirms it, some aren't willing to open the case to speed things up. Yes, we don't sell many millions of units monthly. Best regards, Michal Vodicka UPEK, Inc. [xxxxx@upek.com, http://www.upek.com]=20
  Message 11 of 36  
01 Oct 08 18:30
Mark S. Edwards
xxxxxx@muttsnuts.com
Join Date:
Posts To This List: 394
Skipping IRP stack locations and driver verifier problems

I agree. I do see part of Microsoft's point. Any open access point to report bugs, if not managed to a high degree soon gets the signal drowned out by the noise. I would guess that many of us on here have at times had relationships with Microsoft groups or PM's where simply by reputation of only ever raising something because you have conclusive proof either of the bug or the conditions that cause the bug have allowed you to get things fixed and changed. Then there's that annoying moment when you find the personnel have been moved around and you get ignored because you have no reputation with the new people. I have for many years proposed that Microsoft could setup a system which could be lightly policed. Trusted outsiders (e.g. MVP's as well as other classifications) get added to a portal where they can post bugs. The noise on this portal would be limited and anyone generating noise simply gets removed. There was one annoying incident at the PDC when talking to someone from Microsoft about a bug. The response being that since it hadn't been reported by PSS, it wasn't on their radar. I don't know about anyone else but I have philosophical objections about paying Microsoft $$$ in order to get them to acknowledge let alone fix a bug. These days I'm pretty much with Bill, I can usually find a work around or just document it. Life's too short to obsess on such things. Mark. At 12:35 01/10/2008, Bill McKenzie wrote: >It sure would be nice if we had a constant, consistent and attentive avenue >for reporting this kind of stuff. As it is, I wouldn't even try...I find >error reporting to Microsoft an exercise in futility. Not the end of the >world, but it would be nice. > >Bill M. > > >"David R. Cattley" <xxxxx@msn.com> wrote in message news:112145@ntdev... > >I saw similar issues with a TDI filter and eventually concluded that it was <...excess quoted lines suppressed...>
  Message 12 of 36  
01 Oct 08 18:35
Calvin Guan
xxxxxx@yahoo.ca
Join Date: 15 May 2005
Posts To This List: 308
Skipping IRP stack locations and driver verifier problems

Well, if that was the case, I'd try to bandage it with duct tape given that the problem is well understood. In many cases, a workaround is possible but it can be ugly. In the end, pleasing the customers is important or they don't buy our chips. The drawback is that they might think a "solution" is available hence, won't push for a real fix as hard. Calvin --- On Wed, 10/1/08, Michal Vodicka <xxxxx@upek.com> wrote: > From: Michal Vodicka <xxxxx@upek.com> > Subject: RE: Re:[ntdev] Skipping IRP stack locations and driver verifier problems > To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> > Received: Wednesday, October 1, 2008, 2:41 PM > > -----Original Message----- > > From: xxxxx@lists.osr.com > > [mailto:xxxxx@lists.osr.com] On Behalf > Of Calvin Guan > > Sent: Wednesday, October 01, 2008 11:22 PM > > To: Windows System Software Devs Interest List <...excess quoted lines suppressed...> __________________________________________________________________ Reclaim your name @ymail.com or @rocketmail.com. Get your new email address now! Go to http://ca.promos.yahoo.com/jacko/
  Message 13 of 36  
01 Oct 08 19:01
Michal Vodicka
xxxxxx@upek.com
Join Date: 02 Apr 2004
Posts To This List: 1612
Skipping IRP stack locations and driver verifier problems

> -----Original Message----- > From: xxxxx@lists.osr.com=20 > [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan > Sent: Thursday, October 02, 2008 12:35 AM > To: Windows System Software Devs Interest List > Subject: RE: Re:[ntdev] Skipping IRP stack locations and=20 > driver verifier problems >=20 > Well, if that was the case, I'd try to bandage it with duct=20 > tape given that the problem is well understood. In many=20 <...excess quoted lines suppressed...> Yes, this is what I do sometimes. In parallel with support request waiting in MS priority queue. The ugly part is driver checking installed USB stack version and enabling/disabling workarounds accordingly :) Future driver will be UMDF which has the advantage than most workarounds are simply impossible and there is no discussion about BSOD 'owner' ;-) Best regards, Michal Vodicka UPEK, Inc. [xxxxx@upek.com, http://www.upek.com]=20
  Message 14 of 36  
01 Oct 08 19:27
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2105
Skipping IRP stack locations and driver verifier problems

Keep in mind that verifier is flagging what it thinks is a potential problem from the perspective that it does not *know* that everytime you process this particular IRP that you *always* will skip & forward. The big question not answered is why you got a short IRP to begin with. Was it from a component that did not allocate the IRP correctly or are you getting into the stack after the client has created its IRP pool? Just be sure that you can explain the scenario and handle it robustly and I recommend that you add runtime checking of your own to help replace the I/O Verification that Verifier was trying to do. Good Luck, Dave Cattley Consulting Engineer Systems Software Development -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com Sent: Wednesday, October 01, 2008 3:30 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Skipping IRP stack locations and driver verifier problems Dave, Thank you for the reply. I guess we will disable IO verification and add asserts to our code instead. Thanks, --aydan --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: 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 15 of 36  
01 Oct 08 21:37
Bill McKenzie
xxxxxx@sbcglobal.net
Join Date:
Posts To This List: 236
Skipping IRP stack locations and driver verifier problems

Take your experience and multiply it by about 10 or 12 and that is exactly what I went through with 1394 back when I was an active MVP. Except that some of the bugs I hit never got fixed AFAIK. Some got fixed because big important customers ran into them just like you saw. Glad I am not alone anyway :) Bill M. "Skywing" <xxxxx@valhallalegends.com> wrote in message news:112208@ntdev... <rant> Agree. I had a complex deadlock with smart card removal on an integrated (but internally USB attached) smart card reader that manifested itself across a suspend/resume in Vista x64 RTM that crossed user mode (about 4 different service processes) and kernel mode (PnP) that ultimately was caused by MS code calling LoadLibrary in DllMain (totally no-brainer stupid bug), subsequently stalling things in a PnP service notification via a concoluted chain of RPC calls. I spent about 12 hours of my own time in kd on my own personal box triaging the issue, then I tried to report it to get fixed using one of my (at the time) MVP support incidents. This was a total flop, even through the MVP channel (which, I assume, likely has a much higher chance of getting somewhere than your average small business PSS incident). Despite having debugged the *whole damned problem*, and having shown that it resulted from a bad practice that MSDN explicitly called out, I could not, for the life of me, get PSS to do anything more than acknowledge that the DllMain thing might be a bug and might get entered in a bug database for a future Windows major release. (Of course, they could not follow up if this ever did actually happen.) Fast forward 12 months, and a QFE hotfix is released that fixes the exact problem, (presumably because a large enough customer complained). Ugh. After PSS explicitly told me that there was no way that I could hope for anything other than a bug *maybe* being created for a future Windows release. That sort of thing totally burns me up about reporting issues to Microsoft externally; unless you either 1) know the owner of the component and can get ahold of them directly, or 2) are a megacorp, you get the complete run-around and things don't get fixed, at least not until someone sufficiently important complains. </rant> If you know someone on the inside on the team that owns the broken component, then things are great, but the barrier of getting anything to said team from the outside world is just incredibly, ridiculously painful if you don't have someone's direct email to report stuff via unofficial channels. - S -----Original Message----- From: Bill McKenzie <xxxxx@sbcglobal.net> Sent: Wednesday, October 01, 2008 14:37 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: Re:[ntdev] Skipping IRP stack locations and driver verifier problems It sure would be nice if we had a constant, consistent and attentive avenue for reporting this kind of stuff. As it is, I wouldn't even try...I find error reporting to Microsoft an exercise in futility. Not the end of the world, but it would be nice. Bill M. "David R. Cattley" <xxxxx@msn.com> wrote in message news:112145@ntdev... >I saw similar issues with a TDI filter and eventually concluded that it was > a verifier 'failure' to correctly measure what is going on. > > The issue is that somehow the stack got an IRP without out enough stack > locations for each driver in the stack. Since your driver is the first > one > with verifier enabled (who knows, maybe it is the top of the stack, but no > matter) it is the first chance verifier has to complain about it. > > TDI filtering in particular is so full of bad actors, hacks, and other <...excess quoted lines suppressed...> --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: 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 16 of 36  
01 Oct 08 21:58
Aydan Yumerefendi
xxxxxx@gmail.com
Join Date: 26 Aug 2008
Posts To This List: 31
Skipping IRP stack locations and driver verifier problems

I get a "short" IRP because at the time my filter driver is installed other drivers (e.g., netbt) have been loaded and they do not update their estimate for the depth of the IRP stack until the machine is rebooted. In the case of netbt every time I access a network share all IRPs come "short". On reboot everything works fine, but I cannot force our users to reboot their machines after installation. In fact, running without a reboot has been a major marketing goal and that has caused me a lot of headaches. What I tried to determine with this post was if other people have observed problems with the driver verifier and short IRPs. Based on the responses I would assume that the answer is: yes. Thanks, --aydan
  Message 17 of 36  
01 Oct 08 22:40
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2401
Skipping IRP stack locations and driver verifier problems

Calvin Guan wrote: > Well, if that was the case, I'd try to bandage it with duct tape given that the problem is well understood. In many cases, a workaround is possible but it can be ugly. In the end, pleasing the customers is important or they don't buy our chips. The drawback is that they might think a "solution" is available hence, won't push for a real fix as hard. The poor driver engineer is always guilty for everything. You find a workaround for buggy hardware, and they blame you for being too slow fixing bugs in the driver. You find a workaround for OS bug - same story. You're in the middle... Regards, --PA
  Message 18 of 36  
02 Oct 08 05:37
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
Skipping IRP stack locations and driver verifier problems

> kernel mode (PnP) that ultimately was caused by MS code calling LoadLibrary in > DllMain (totally no-brainer stupid bug) "Flames" seem to be all over the place.......and I am not even participating in this thread..... Anton Bassov
  Message 19 of 36  
03 Oct 08 20:30
Lyndon J. Clarke
xxxxxx@neverfailgroup.com
Join Date: 10 Nov 2003
Posts To This List: 227
Skipping IRP stack locations and driver verifier problems

No time to lose, anton, no time to lose :-) <xxxxx@hotmail.com> wrote in message news:112237@ntdev... >> kernel mode (PnP) that ultimately was caused by MS code calling >> LoadLibrary in >> DllMain (totally no-brainer stupid bug) > > "Flames" seem to be all over the place.......and I am not even > participating in this thread..... > > > Anton Bassov >
  Message 20 of 36  
08 Oct 08 17:35
Lukas Rypacek
xxxxxx@asw.cz
Join Date: 13 Aug 2004
Posts To This List: 7
Skipping IRP stack locations and driver verifier problems

Hi, I don't know if the original topic is already lost in rant, but I have also seen this netbt bug and I assume everyone who tried to deploy a TDI filter must have already dealt with it. It can be avoided by issuing a newly allocated IRP with enough stack locations instead of the short one, or skipping the location, if that is the option. As I understand it, skipping the current stack location is OK, however, when driver verifier is enabled, is uses the stack location your driver would otherwise use (but didn't) for its own completion routine. In effect, even if your driver would call IoSkipCurrentIrpStackLocation( ), that stack location would be used for driver verifier. From this point of view it is not a false positive, since the IRP is truly too short to run with Verifier :-) An experienced driver developer from Microsoft has suggested to me that we should check for the Verifier presence and only call IoSkipCurrentIrpStackLocation( ) if Verifier is not loaded. Lukas R.
  Message 21 of 36  
08 Oct 08 17:41
Chris Aseltine
xxxxxx@gmail.com
Join Date: 23 Sep 2006
Posts To This List: 1221
Skipping IRP stack locations and driver verifier problems

Lukas Rypacek wrote: > An experienced driver developer from Microsoft has suggested to > me that we should check for the Verifier presence and only call > IoSkipCurrentIrpStackLocation( ) if Verifier is not loaded. Brilliant. Maybe we can find other "solutions" by replacing "Verifier" with "DTM"...
  Message 22 of 36  
08 Oct 08 17:51
Lukas Rypacek
xxxxxx@asw.cz
Join Date: 13 Aug 2004
Posts To This List: 7
Skipping IRP stack locations and driver verifier problems

Chris Aseltine wrote: >Brilliant. Maybe we can find other "solutions" by replacing "Verifier" with > "DTM"... True. On the other hand, it is a pitty not to use Verifier's IO verification for your TDI driver at all. Knowing about this bug and dealing with it (e.g. with this sort of DEBUG trick) can actually help you more. Or not?
  Message 23 of 36  
08 Oct 08 20:07
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2105
Skipping IRP stack locations and driver verifier problems

<LukasR> An experienced driver developer from Microsoft has suggested to me that we should check for the Verifier presence and only call IoSkipCurrentIrpStackLocation( ) if Verifier is not loaded. </LucasR> I have great trouble believing that this was actually suggested by someone even remotely familiar with how the DV monitors IRP progress. First of all, you *must* skip the location if you are not going to use it. Otherwise, you are just wasting an I/O Stack Location and you have already determined that in this case, there are not enough. This is just going to make it bugcheck anyway. Second, I seriously doubt that DV "... uses the stack location your driver would otherwise use (but didn't)..." since DV is very good about *not* changing anything about the IRP that a driver could otherwise see. This would be a very visible thing for a driver to see. It has always been my understanding that DV hides it's context for IRP away in a safe spot away from prying eyes. And yes, NETBT, AFD, and RASPPTP are all rather poor TDI clients. Some use fixed size IRPs of a maximum value; others never bother to call IoGetRelatedDeviceObject() and send IRPs to the bottom of the stack; some can't be bothered to even allocate an IRP with more than two stacks (one for itself, one for TCPIP). The whole thing is a rather sad state of affairs when you mix in the number of bad TDI filters that have been written over the years. That is what makes it all fun, wouldn't ya say? Good Luck, Dave Cattley Consulting Engineer Systems Software Development -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@asw.cz Sent: Wednesday, October 08, 2008 5:35 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Skipping IRP stack locations and driver verifier problems Hi, I don't know if the original topic is already lost in rant, but I have also seen this netbt bug and I assume everyone who tried to deploy a TDI filter must have already dealt with it. It can be avoided by issuing a newly allocated IRP with enough stack locations instead of the short one, or skipping the location, if that is the option. As I understand it, skipping the current stack location is OK, however, when driver verifier is enabled, is uses the stack location your driver would otherwise use (but didn't) for its own completion routine. In effect, even if your driver would call IoSkipCurrentIrpStackLocation( ), that stack location would be used for driver verifier. From this point of view it is not a false positive, since the IRP is truly too short to run with Verifier :-) An experienced driver developer from Microsoft has suggested to me that we should check for the Verifier presence and only call IoSkipCurrentIrpStackLocation( ) if Verifier is not loaded. Lukas R. --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: 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 24 of 36  
08 Oct 08 21:55
Calvin Guan
xxxxxx@yahoo.ca
Join Date: 15 May 2005
Posts To This List: 308
Skipping IRP stack locations and driver verifier problems

--- On Wed, 10/8/08, David R. Cattley <xxxxx@msn.com> wrote: > From: David R. Cattley <xxxxx@msn.com> > First of all, you *must* skip the location if you are not > going to use it. Eh? I think I could just IoCopy* if I don't skip. > Otherwise, you are just wasting an I/O Stack Location Worse yet, the lower driver sees uninitialized stack which would draw beautiful whites on blue, because IoCallDriver advances stack before handing the irp to the lower. -- Calvin Guan Broadcom Corp. Connecting Everything(r) __________________________________________________________________ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/
  Message 25 of 36  
08 Oct 08 22:55
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2105
Skipping IRP stack locations and driver verifier problems

Calvin, Of course you are correct! If enough stack locations existed you could just copy the current to the next and call IoCallDriver. The OP is in the situation, however, where the number of I/O stack locations in the IRP are not sufficient. That is why I emphasized *must* skip. I do think it rather pointless, however, if one just copies the stack location and does not set a CRTN. What is accomplished other than burning a IOSL? Maybe I am too naive to see the subtly of doing this. I it just seems a waste of an IOSL to me... Cheers, -dave -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan Sent: Wednesday, October 08, 2008 9:55 PM To: Windows System Software Devs Interest List Subject: RE: [ntdev] Skipping IRP stack locations and driver verifier problems --- On Wed, 10/8/08, David R. Cattley <xxxxx@msn.com> wrote: > From: David R. Cattley <xxxxx@msn.com> > First of all, you *must* skip the location if you are not > going to use it. Eh? I think I could just IoCopy* if I don't skip. > Otherwise, you are just wasting an I/O Stack Location Worse yet, the lower driver sees uninitialized stack which would draw beautiful whites on blue, because IoCallDriver advances stack before handing the irp to the lower. -- Calvin Guan Broadcom Corp. Connecting Everything(r) __________________________________________________________________ Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! Canada Messenger at http://ca.beta.messenger.yahoo.com/ --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: 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 26 of 36  
09 Oct 08 00:24
Calvin Guan
xxxxxx@yahoo.ca
Join Date: 15 May 2005
Posts To This List: 308
Skipping IRP stack locations and driver verifier problems

> From: David R. Cattley <xxxxx@msn.com> > Subject: RE: [ntdev] Skipping IRP stack locations and driver verifier problems > I do think it rather pointless, however, if one just copies > the stack > location and does not set a CRTN. What is accomplished > other than burning a > IOSL? You're right Dave, it doesn't do anything useful. I thought the problem was "DV asserts if and only if I call IoSkipXxx". If the problem is lack of stack location, if I'm desperate and if I'm just doing it for fun, I would attempt to switch IO stack location on its way down and switch back in the completion routine. (There are a lot of IFs here:)) Calvin __________________________________________________________________ Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/
  Message 27 of 36  
09 Oct 08 01:45
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
Skipping IRP stack locations and driver verifier problems

> even if your driver would call IoSkipCurrentIrpStackLocation( ), that stack location would be > used for driver verifier. Not really.... The very term 'skip' is a bit misleading here - it would be better to say "reuse". Although the very name IoSkipCurrentIrpStackLocation( ) somehow suggests that current stack location gets skipped so that you proceed to the next one, in actuality this is not what happens -instead, stack pointer gets decremented, subsequent call to IoCallDriver() advances it, and, as a result, when the lower driver's dispatch routine gets invoked, stack pointer is at exactly the same position it used to be at when your driver's dispatch routine got invoked. In other words, all unused stack locations are ahead of the stack pointer, rather than behind it. Therefore, if verifier tries to make any use of a stack location that you skip with IoSkipCurrentIrpStackLocation( ), it is going to screw up lower driver's operations.... Anton Bassov
  Message 28 of 36  
09 Oct 08 10:03
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Skipping IRP stack locations and driver verifier problems

<QUOTE> Therefore, if verifier tries to make any use of a stack location that you skip with IoSkipCurrentIrpStackLocation( ), it is going to screw up lower driver's operations.... </QUOTE> Huh? I don't understand your point, Anton. I THINK the analysis presented up to this point was correct, and reasonably complete. What are you trying to add? When you have I/O Verification enabled for Driver Verifier, Verifier (itself) needs an I/O completion callback. So, even if you call IoSkipCurrentIrpStackLocation(), Verifier does the equivalent of IoCopyCurrentIrpStackLocationToNext(). That's the whole point here, as I understand it. While I agree that IoSkipCurrentIrpStackLocation is poorly named, it's just one of a number of badly named I/O functions that come from an era where there was a lot of work going on and not nearly enough attention was paid to what the functions were named... Peter OSR
  Message 29 of 36  
09 Oct 08 11:22
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
Skipping IRP stack locations and driver verifier problems

> I don't understand your point, Anton. I THINK the analysis presented up to this point was correct, > and reasonably complete. What are you trying to add? Actually, I am just trying to understand how it does things, i.e. WHY it all happens and what it does wrong.... > When you have I/O Verification enabled for Driver Verifier, Verifier (itself) needs > an I/O completion callback. So, even if you call IoSkipCurrentIrpStackLocation(), > Verifier does the equivalent of IoCopyCurrentIrpStackLocationToNext(). Please note that both IoCopyCurrentIrpStackLocationToNext() and IoSkipCurrentIrpStackLocation() are just macros, rather than kernel exports. Therefore, it has no chance to do anything before you call IoCallDriver(), so that must be playing its tricks on IRP when you pass it down the stack, i.e. simply hooks IoCallDriver() in your driver's IAT on order to monitor outgoing packets, and your driver's Dispatch routine in order to monitor incoming ones.. . If you register your completion routine and IoCopyCurrentIrpStackLocationToNext() , its task of registering its own completion routine is pretty easy - this involves nothing more than just hooking your routine by changing function pointer in IRP. However, if you just skip a stack location, it has, indeed, make its own equivalent of IoCopyCurrentIrpStackLocationToNext(), so that it must be able to make a distinction between these two scenarios by monitoring stack pointer. Apparently, there must be some bug in this part of Verifier's code.... > While I agree that IoSkipCurrentIrpStackLocation is poorly named... As you can see it yourself, in actuality, the long meaningful IoSkipCurrentIrpStackLocation() may be as misleading as some cryptic skip_loc() or any other name that you have to decypher... Anton Bassov
  Message 30 of 36  
09 Oct 08 11:44
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Skipping IRP stack locations and driver verifier problems

<QUOTE> Apparently, there must be some bug in this part of Verifier's code.... </QUOTE> I'm not going to bite on your trolling, but there IS no bug in Verifier in this instance. Did you actually take the time to read the docs on these functions and read the source because they're macros, or are you just going by intuition and feel? I know that doing your homework before you rant/troll isn't necessarily your style. When you enable I/O Verification, Verifier needs an I/O Stack Location for a completion routine. It won't have that if your driver "skips" the stack location by calling IoSkipCurrentIrpStackLocation. Ergo, Verifier uses an I/O Stack Location (thus doing the equivalent of IoCopyCurrentIrpStackLocationToNext) even in the case when your driver indicates that the system should re-use the current one (by calling IoSkipCurrentIrpStackLocation). Not hard to understand, I don't think. I'm out of this thread, but do feel free to rant or troll further. Maybe you'd like to provide an extended analysis of the names of every Windows kernel function and whether, in your opinion, it is or is not well and sufficiently economically named. Perhaps provide a table of names that you'd prefer for each? Old Name, New Name, Short Name... I'm sure that'd be interesting to a lot of folks on this list. Peter OSR
  Message 31 of 36  
09 Oct 08 12:38
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
Skipping IRP stack locations and driver verifier problems

> there IS no bug in Verifier in this instance. Why does the properly-written driver crash then??? > Did you actually take the time to read the docs on these functions and read the source > because they're macros,or are you just going by intuition and feel Did you actually take the time to read my post which says that, unlike IoCallDriver(), both IoCopyCurrentIrpStackLocationToNext() and IoSkipCurrentIrpStackLocation() are just macros, rather than kernel exports, or are you just going by intuition and feel (i.e. intuitively feel that I am about to criticize MSFT for something)??? Although you do have a good reason to feel so, based upon my numerous posts, on this particular occasion you are plainly wrong.... > I know that doing your homework before you rant/troll isn't necessarily your style. Well, I am afraid in this respect I am just a kid compared to you - as I can see, you have really a supra-natural ability to argue with posts without actually even reading them... > When you enable I/O Verification, Verifier needs an I/O Stack Location for a completion routine. > It won't have that if your driver "skips" the stack location by calling IoSkipCurrentIrpStackLocation. > Ergo, Verifier uses an I/O Stack Location (thus doing the > equivalent of IoCopyCurrentIrpStackLocationToNext) even in the case when your driver > indicates that the system should re-use the current one (by calling IoSkipCurrentIrpStackLocation). Actually, this is exactly what I said in my post, but, as we have already established, you did not even bother yourself with reading it - instead, you went straight to accusations. The only thing I am speaking about is the moment when it does the above - I believe it must be the one when you call IoCallDriver()... > Perhaps provide a table of names that you'd prefer for each? Look - you are the only one who, for the reasons better known to himself, speaks about names and naming conventions. In case if I wanted to troll, I would rather choose something more substantial than that. Apparently, you just missed the sarcasm of my statement - just few days ago you attacked UNIX naming convention (which, is, indeed, inconvenient - I don't argue about it), so that my statement was meant just to demonstrate how insignificant this topic is... Anton Bassov
  Message 32 of 36  
09 Oct 08 13:42
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 1065
Skipping IRP stack locations and driver verifier problems

> Look - you are the only one who, for the reasons better known to himself, > speaks about names and naming conventions. In case if I wanted to troll, I > would rather choose something more substantial than that. Apparently, you > just missed the sarcasm of my statement - just few days ago you attacked > UNIX naming convention (which, is, indeed, inconvenient - I don't argue > about it), so that my statement was meant just to demonstrate how > insignificant this topic is... I breaking all the rules of thread hijacking, sorry, well not so sorry :-(. Here is one thing I want to point you out Anton, and it has nothing to do with you or Peter or anyone else... Well, there are a lot of things to worry about naming, and it is a big part of software... You will develop with short name, but people who are behind you line up to maintain ( hence eating away most of the budget) really need those naming right along with lots of other stuff... It is very very significant ... As I said before, I deal with over a million line of source ( C, C++, some ASM ) open and closed source... And I can tell how hard it is to manage these when naming conventions are bad... Once again, this is no flaming. But for commercial product, do not encourage those cryptic names etc... And please note, whoever does their job dealing with it is more important than who creates the mess ... -pro
  Message 33 of 36  
09 Oct 08 17:40
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4384
Skipping IRP stack locations and driver verifier problems

> Well, there are a lot of things to worry about naming, and it is a big part of software... Well, by "insignificant" I meant "insignificant as a point to argue about"...... > You will develop with short name, but people who are behind you line up to maintain Well, I definitely would not develop it with a short name when writing Windows code, and vice versa... > I deal with over a million line of source ( C, C++, some ASM ) open and closed source... > And I can tell how hard it is to manage these when naming conventions are bad... I would say the best thing to do here is just to stick to the generally accepted convention of the OS you write your code for -even if you don't like it. If you combine it with proper comments, it seems to be just a wonderful way to stay friends with those who maintain/integrate/etc your code... Anton Bassov
  Message 34 of 36  
09 Oct 08 19:16
ntdev member 32707
xxxxxx@gmail.com
Join Date:
Posts To This List: 141
Skipping IRP stack locations and driver verifier problems

OK then, for a moment I just wanted to flush out my thoughts ... Now make sense, so ... end of offtopic... -pro On Thu, Oct 9, 2008 at 2:40 PM, <xxxxx@hotmail.com> wrote: > > Well, there are a lot of things to worry about naming, and it is a big > part of software... > > Well, by "insignificant" I meant "insignificant as a point to argue > about"...... > > > You will develop with short name, but people who are behind you line up > to maintain > > Well, I definitely would not develop it with a short name when writing <...excess quoted lines suppressed...> --
  Message 35 of 36  
10 Oct 08 07:19
Volodymyr M. Shcherbyna
xxxxxx@mvps.org
Join Date: 09 May 2008
Posts To This List: 40
Skipping IRP stack locations and driver verifier problems

To OP: I also met this problem in past: http://msmvps.com/blogs/v_scherbina/archive/2008/01/16/driver-verifier-iomanager- violation-in-windows-server-2003-sp2-with-latest-updates-on.aspx I sent a question to WNDP, and here is a reply I recieved from them: date 5 février 2008 18:14 objet FW: (Windows Core Networking) : an issue with Server 2003 SP2 >> I had a brief look at the verifier code which gives this break, it could be a little over zealous. It seems to break if there are <= 2 stack locations left in the Irp. This shouldn't be a big issue as it won't happen without verifier. He can probably increment the DeviceObject->StackSize by 2 as a work around to the problem. >> Please also ask him if setting a completion routine in the Irp solves his >> problem. Thanks Praveen << HTH, -- Volodymyr, blog: http://www.shcherbyna.com/ (This posting is provided "AS IS" with no warranties, and confers no rights) <xxxxx@garlic.com> wrote in message news:112530@ntdev... >> Look - you are the only one who, for the reasons better known to himself, >> speaks about names and naming conventions. In case if I wanted to troll, >> I >> would rather choose something more substantial than that. Apparently, you >> just missed the sarcasm of my statement - just few days ago you attacked >> UNIX naming convention (which, is, indeed, inconvenient - I don't argue >> about it), so that my statement was meant just to demonstrate how >> insignificant this topic is... > > I breaking all the rules of thread hijacking, sorry, well not so sorry <...excess quoted lines suppressed...>
  Message 36 of 36  
31 Oct 08 11:47
ntdev member 40827
xxxxxx@microsoft.com
Join Date:
Posts To This List: 26
Skipping IRP stack locations and driver verifier problems

I currently believe Verifier was well-intentioned here, but overaggressive. It was trying to point out that *if one of the drivers on this device stack will change its design in the future, and not Skip the stack location anymore*, then the IRP will run out of stack locations. That scenario is conceivable but some folks pointed out that they will *never* change their IoSkipCurrentIrpStackLocation design, therefore Verifier was overaggressive in their particular scenario. Thanks to those of you who talked with me about this at the DDC! So we decided to remove this check from future OS versions. On older OS versions, I believe users have to continue after this kernel debugger break, or disable the Enhanced I/O Verification if they are blocked by it. Please feel free to follow-up on verifier @ microsoft.com about this issue or anything else related to Verifier. Thanks, Dan
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 02:31.


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