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 38  
10 May 17 05:06
ntdev member 172937
xxxxxx@dirac.com
Join Date:
Posts To This List: 6
Visual Studio debug breakpoints not hit

Hi all, I'm using VS 2015 to try to debug an audio driver (x64), so I have setup a = Win10 virtualbox machine, and I've managed to provision it for development.= When I start the debugging, driver is deployed and installed and I can see= the log outputs via DebugView. However, none of the breakpoints I've set are hit. Ideas? Regards /Robert
  Message 2 of 38  
10 May 17 08:52
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

MY idea is to not use VS to debug your driver, and instead we use WinDbg stand alone. I recognize that may not be helpful... but that's what I recommend. Peter OSR @OSRDrivers
  Message 3 of 38  
10 May 17 14:58
matt sykes
xxxxxx@hotmail.com
Join Date:
Posts To This List: 203
Visual Studio debug breakpoints not hit

@Peter, that is an easy response, but, if we don't want to live in the past, perhaps there is some benefit to using VS2015? If it cant do .kdfiles then VS is useless of course, this is one of the best features of Windbg, but if it can, and do all the other things...? But, as you say, we tend to gravitate to Windbg. In fact I use it for usermode debugging too, so useful is it. Perhaps OSR should do an article on it, the relative merits, or not, of VS vs Windbg? What say you Pater?
  Message 4 of 38  
10 May 17 16:13
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> if we don't want to live in the past, perhaps there is some benefit to using VS2015? </quote> If there is some benefit, I am not aware of it. It's not about living in the past, Mr. Sykes. The issue is that the Visual Studio environment does not match how people I know develop and debug drivers. The work flow is broken. You won't find the Windows core devs in Redmond using VS to debug the OS, I can guarantee you that. In my own practice, I do not want to constantly be connecting to and disconnecting from my target system, for example. Nor do I want my code editor to freeze and prevent me from making code changes whilst I'm in the debugger. See: <https://www.osr.com/nt-insider/2011-issue3/five-things-like-visual-studio-integr ation-2/> Not to mention setting up the debugger via VS is a significant PITA relative to setting it up in WinDbg. And then there's the whole "deploy and test" thing that's built into VS and the WDK. I *have* seen it work three times: Once I saw the owning feature PM demo it for me in a conference room in Building 27, I subsequently got it to work on my own system once but never again, and the third time, I saw the dev owner make it work in his office. The deploy/test thing would be great if it worked 100%. And double more if I could fire-it-up from the Enterprise WDK so my CI stream could fire-off tests. But I digress. Peter OSR @OSRDrivers
  Message 5 of 38  
10 May 17 16:39
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 53
Visual Studio debug breakpoints not hit

On Wed, May 10, 2017 at 3:12 PM, <xxxxx@osr.com> wrote: > <quote> > if we don't want to live in the past, > perhaps there is some benefit to using VS2015? > </quote> > > If there is some benefit, I am not aware of it. > > It's not about living in the past, Mr. Sykes. The issue is that the Visu= al Studio environment does not match how people I know develop and debug dr= ivers. The work flow is broken. You won't find the Windows core devs in R= edmond using VS to debug the OS, I can guarantee you that. > > In my own practice, I do not want to constantly be connecting to and disc= onnecting from my target system, for example. Nor do I want my code editor= to freeze and prevent me from making code changes whilst I'm in the debugg= er. > > See: <https://www.osr.com/nt-insider/2011-issue3/five-things-like-visual-= studio-integration-2/> > > Not to mention setting up the debugger via VS is a significant PITA relat= ive to setting it up in WinDbg. And then there's the whole "deploy and tes= t" thing that's built into VS and the WDK. I *have* seen it work three tim= es: Once I saw the owning feature PM demo it for me in a conference room i= n Building 27, I subsequently got it to work on my own system once but neve= r again, and the third time, I saw the dev owner make it work in his office= . The deploy/test thing would be great if it worked 100%. And double more= if I could fire-it-up from the Enterprise WDK so my CI stream could fire-o= ff tests. But I digress. > > Peter > OSR > @OSRDrivers > This is a refreshing comment as it is basically my experience. Unfortunately, I've still had issues getting a working workflow and being able to forcefully load KMDF PnP drivers with either DevCon or my custom code. I did sink quite a bit of time into attempting to use VS2015 because, for some reason or other, the WDK is tied to it and there is very little (or no) information on using anything else published by Microsoft.
  Message 6 of 38  
10 May 17 22:30
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> I did sink quite a bit of time into attempting to use VS2015 because, for some reason or other, the WDK is tied to it </quote> I didn't say don't use VS. I said don't use the DEBUGGER via VS. And further the cursed "deploy" and "test" thing doesn't work. At least not yet, (RS 1 WDK still I. Use) and not for me. This isn't really refreshing, it's the standard view of most of the experienced devs that has been stated here repeatedly. You do want to write and build your code using VS. Or, at least, I do. It's gone from being a sodding PITA ten years ago to a very good development environment, even for drivers (mins the test/debug shit). Peter OSR @OSRDrivers
  Message 7 of 38  
11 May 17 01:35
ntdev member 172937
xxxxxx@dirac.com
Join Date:
Posts To This List: 6
Visual Studio debug breakpoints not hit

Hi Peter et al, Well, I got it to work finally by attaching VS to the kernel process of the VM. And it beats the *crap* out of the cumbersome windbg experience... 😝 All the best /Robert > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-631121- > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com > Sent: den 10 maj 2017 22:13 > To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> > Subject: RE:[ntdev] Visual Studio debug breakpoints not hit > > <quote> > if we don't want to live in the past, <...excess quoted lines suppressed...>
  Message 8 of 38  
11 May 17 03:36
ntdev member 172937
xxxxxx@dirac.com
Join Date:
Posts To This List: 6
Visual Studio debug breakpoints not hit

And as fast as it started working, it stopped working. But as long as it did, it was awesome... ☹ /R > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-631156- > xxxxx@lists.osr.com] On Behalf Of Robert Bielik > Sent: den 11 maj 2017 07:35 > To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> > Subject: RE: RE:[ntdev] Visual Studio debug breakpoints not hit > > Hi Peter et al, > <...excess quoted lines suppressed...>
  Message 9 of 38  
11 May 17 08:42
ntdev member 172937
xxxxxx@dirac.com
Join Date:
Posts To This List: 6
Visual Studio debug breakpoints not hit

Hmm... it only seems to work reliably using "serial port" (via named pipe to the VM). So, awesomeness again 😉 /R > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-631164- > xxxxx@lists.osr.com] On Behalf Of Robert Bielik > Sent: den 11 maj 2017 09:35 > To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> > Subject: RE: RE:[ntdev] Visual Studio debug breakpoints not hit > > And as fast as it started working, it stopped working. But as long as it did, it > was awesome... ☹ <...excess quoted lines suppressed...>
  Message 10 of 38  
11 May 17 10:01
Peter Brown
xxxxxx@outlook.com
Join Date: 21 Mar 2017
Posts To This List: 7
Visual Studio debug breakpoints not hit

Greetings Mr. Bielik, Your experience matches my own, in that debugging with VS is an on-again, off-again exercise in futility. I don't even bother now and have learned to work with WinDBG(a bit of a learning-curve, but well worth it). It is my hope that when WDK is (finally) integrated with VS-2017, that the debugging issues will have been ironed out. Truthfully, I do miss the DDK way of doing things and not using VS at all. Although, I primarily write Kernel Extension and so rarely have had to slay the WDM PnP Beast. Best, PT
  Message 11 of 38  
11 May 17 11:13
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Visual Studio debug breakpoints not hit

You need to instances of VS : one for editing, building and deploying the project, the second for debugging. Now both VS and WinDbg use « Debugging tools for Windows ». The only difference is that VS consumes a lot more memory. I suggest you learn to build a WinDbg command line containing all debug settings. This is not difficult of course and you will end up with a shortcut on the desktop. Debugging a test machine will than be as easy as double-clicking the WinDbg shortcut and starting the test machine. For those of us who have a lot of RAM, this can be done with VS. It’s a matter of a few clicks. W. N.
  Message 12 of 38  
11 May 17 12:19
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Visual Studio debug breakpoints not hit

Sorry, I meant ? two instances ? and not ? to instances ? W. N. De : xxxxx@outlook.com<mailto:xxxxx@outlook.com> Envoy? le :jeudi 11 mai 2017 17:13 ? : Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Objet :RE:[ntdev] Visual Studio debug breakpoints not hit You need to instances of VS : one for editing, building and deploying the project, the second for debugging. Now both VS and WinDbg use ? Debugging tools for Windows ?. The only difference is that VS consumes a lot more memory. I suggest you learn to build a WinDbg command line containing all debug settings. This is not difficult of course and you will end up with a shortcut on the desktop. Debugging a test machine will than be as easy as double-clicking the WinDbg shortcut and starting the test machine. For those of us who have a lot of RAM, this can be done with VS. It?s a matter of a few clicks. W. N. --- 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 13 of 38  
11 May 17 12:49
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> And it beats the *crap* out of the cumbersome windbg experience </quote> Interesting. Mr. Bielik, Would you take the time to explain to me how you find the VS debugging experience superior, and the WinDbg experience "cumbersome"? I'm not looking for you to convince me, or vice-versa. Everyone should choose the tools that best suit them. Rather, I'm curious if there's something I'm overlooking in how I present this topic to our students and would appreciate your help. <quote> Truthfully, I do miss the DDK way of doing things and not using VS at all. </quote> You don't HAVE to use VS at all... you know that, right? You can build from the command line using MSBUILD, using either the VS-coupled WDK or the Enterprise WDK (no VS required). Peter OSR @OSRDrivers
  Message 14 of 38  
11 May 17 12:56
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11663
Visual Studio debug breakpoints not hit

xxxxx@osr.com wrote: > <quote> > Truthfully, I do miss the DDK way of doing things and not > using VS at all. > </quote> > > You don't HAVE to use VS at all... you know that, right? > > You can build from the command line using MSBUILD, using either the VS-coupled WDK or the Enterprise WDK (no VS required). That's exactly what I do. I edit with vim, where I am most productive, and build by running "msbuild" from the command line. I simply do not have the patience to wait for Visual Studio to start up. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 15 of 38  
11 May 17 13:31
Bo Brantén
xxxxxx@acc.umu.se
Join Date: 16 Jun 2015
Posts To This List: 28
Visual Studio debug breakpoints not hit

On Thu, 11 May 2017, xxxxx@osr.com wrote: > You don't HAVE to use VS at all... you know that, right? > > You can build from the command line using MSBUILD, using either the VS-coupled WDK or the Enterprise WDK (no VS required). To mention a few drawbacks of the EWDK: There is no tool to create a new empty project. Is is not possible to compile most test applications while the old WDK could compile many but not all applications. Bo Branten
  Message 16 of 38  
11 May 17 14:04
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Visual Studio debug breakpoints not hit

« Visual Studio debug breakpoints not hit » With the humble but very powerful WinDbg, this would be as easy as : 1. Clicking the pause button to break into the debuggee (target). 2. Issue the WinDbg command : bp Mydriver!Myfunction 1. Hit the F5 key to let the debuggee run again. Once the function is executed, the debugger should break and a window containing the source code should pop-up. J. S.
  Message 17 of 38  
11 May 17 16:42
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 53
Visual Studio debug breakpoints not hit

On Thu, May 11, 2017 at 12:30 PM, Bo Branten <xxxxx@acc.umu.se> wrote: > On Thu, 11 May 2017, xxxxx@osr.com wrote: > >> You don't HAVE to use VS at all... you know that, right? >> >> You can build from the command line using MSBUILD, using either the >> VS-coupled WDK or the Enterprise WDK (no VS required). > > > To mention a few drawbacks of the EWDK: > <...excess quoted lines suppressed...> This is one of the problems I had, but it extends to most of what you would want to do with a driver. To its credit, the menus in VS are discoverable and very goal oriented, although the implementation of those features is sometimes broken. If one wants to eschew VS they are left with minimal documentation on how most common things one would want to do (install a PnP driver for testing, debug a driver, generate an empty project file or adjust WDK settings for MSBuild). This is kind of unfortunate because the MSDN documentation seems to be written with an eye to supporting both options, but it's very hard to impossible to not use VS. The only progress I made involved trying to reverse engineer what VS was doing. It was very hard to find out - most importantly - what I needed to do. The how is sometimes there but you have no idea that's what you need to be looking at. It seems like the OP solved their original problem, and I suppose the information that serial debugging works better is welcome. I tried to debug a VM but it seems increasingly necessary to have a separate computer for some reason.
  Message 18 of 38  
11 May 17 17:51
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> There is no tool to create a new empty project. </quote> I was going to be smug and write something that started with "SERIOUSLY?"... and then I realized that this actually IS a bit of a PITA. Interesting oversight. <quote> Is is not possible to compile most test applications while the old WDK could compile many but not all applications. </quote> This isn't JUST an EWDK limitation... it's a WDK limitation. The fact that you can have a Solution that includes components from the WDK *and* an actual, real, application of some kind (you know, in C# or whatever) is a feature of VS integration. The old WDK allowed you to build some applications, but it was getting increasingly crufty. @R0b0t1: In terms of how you figure all this out... I grant you there's an inordinate amount of documentation that directs you to use VS for all things... including deployment and test machines and debugging. But how to setup debugging manually IS pretty well documented now (it took about 15 years to get it all written up clearly... no joke). And there's really very little way for somebody who's not already a community member to know that a lot of the VS integrated deploy/test/debug stuff just doesn't work. Because, it doesn't. For every version of the "push a button to run driver tests" (you know, setting up test machines, and automatic deployment and such)... I've had the PM tell me "THIS version works. Really!" and when the NEXT version is ready to ship they said "Yes, we realize that the PREVIOUS version DID NOT WORK. AT ALL. Completely broken. But I SWEAR to you, this next version works." Rinse and repeat. I don't know how a new dev comes to learn that... but that's the computer industry for you. In fairness: I HAVE NOT TRIED THIS FEATURE IN THE RS3 WDK YET. Maybe it works great now. The dev who owns this feature is clever, and really wants to make it work. SO, maybe the third time is a chamr? Peter OSR @OSRDrivers
  Message 19 of 38  
12 May 17 02:59
ntdev member 172937
xxxxxx@dirac.com
Join Date:
Posts To This List: 6
Visual Studio debug breakpoints not hit

Hi Peter, > Interesting. Mr. Bielik, Would you take the time to explain to me how you > find the VS debugging experience superior, and the WinDbg experience > "cumbersome"? Well, superior is a strong word, as is the sentence "beats the crap out of" 😉 But, now that I finally got it to work, the things I prefer in VS is the ability to set breakpoints, step through code, check variable values all very easily in an environment I'm very familiar with. So I'd say me thinking BTCOO was from my point of view 😊 > I'm not looking for you to convince me, or vice-versa. Everyone should > choose the tools that best suit them. Rather, I'm curious if there's something > I'm overlooking in how I present this topic to our students and would > appreciate your help. I see. Somehow I'd still recommend going the "hard way", at least until issues like I experienced (like having problems debugging with the "Network" setting) are, ironed out, as someone said. If I were a student, I think I would learn a lot going this way. It is, after all, how I developed my first driver. All the best /Robert > > Peter > OSR > @OSRDrivers > > > --- > NTDEV is sponsored by OSR > <...excess quoted lines suppressed...>
  Message 20 of 38  
12 May 17 11:22
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Visual Studio debug breakpoints not hit

Newbies must read docs and if you read docs you have: "Given any two computers, it is likely that they will both have Ethernet adapters. It is less likely that they will both have serial ports or both have 1394 ports." To me this sounds like: forget about serial ports, use network links. It is there: https://msdn.microsoft.com/en-us/library/windows/hardware/hh439353(v=vs.85).aspx W. N.
  Message 21 of 38  
12 May 17 11:49
matt sykes
xxxxxx@hotmail.com
Join Date:
Posts To This List: 203
Visual Studio debug breakpoints not hit

@Peter, I guess thats as good an answer as we need. Don't use VS, it sucks!
  Message 22 of 38  
12 May 17 15:50
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Visual Studio debug breakpoints not hit

Actually a second instance of VS used for debugging a target consumes only 10 to 15 more MB than WinDbg. So if you prefer VS,use VS and if you prefer WinDbg, use WinDbg. There isn’t any difference. W. N.
  Message 23 of 38  
12 May 17 16:46
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> In fairness: I HAVE NOT TRIED THIS FEATURE IN THE RS3 WDK YET. </quote> While correct, the above was meant to refer to the RS2 WDK.., not the RS3 WDK. I'm in the middle of several projects, and I have this "thing" about changing tool chains in mid-project. I just will never do it. So I have yet to update to the RS 2 WDK (which still uses VS 2015). Peter PSR @OSRDrivers
  Message 24 of 38  
12 May 17 17:20
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3218
Visual Studio debug breakpoints not hit

@Peter, I take that you've never tried Windows Remote Debugger. Lucky you. It's a terribly slow tunnel to a KDBG. We had to use that abomination to connect to SUT at Microsoft to debug problems with our driver.
  Message 25 of 38  
12 May 17 17:22
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 3218
Visual Studio debug breakpoints not hit

To be failr, Windbg GUI is a bit old school, and it hangs when your KDNET target drops off. But it's still the king.
  Message 26 of 38  
12 May 17 17:36
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> I take that you've never tried Windows Remote Debugger. Lucky you. </quote> I don't know what I might have said that would cause you o infer that. But... yes, I have. Mostly on the same corporate LAN... but at OSR we've done it remotely via WAN as well. Not a great experience, for sure. But POSSIBLE, which is pretty damn cool if you ask me. Peter OSR @OSRDrivers
  Message 27 of 38  
12 May 17 20:24
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 744
Visual Studio debug breakpoints not hit

I?m still waiting for the VS team to fix the code analysis features they broke by ?modernizing? the compiler for VS2015. Any bets on who?s issue will be resolved first? Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: xxxxx@osr.com<mailto:xxxxx@osr.com> Sent: May 11, 2017 5:50 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Visual Studio debug breakpoints not hit <quote> There is no tool to create a new empty project. </quote> I was going to be smug and write something that started with "SERIOUSLY?"... and then I realized that this actually IS a bit of a PITA. Interesting oversight. <quote> Is is not possible to compile most test applications while the old WDK could compile many but not all applications. </quote> This isn't JUST an EWDK limitation... it's a WDK limitation. The fact that you can have a Solution that includes components from the WDK *and* an actual, real, application of some kind (you know, in C# or whatever) is a feature of VS integration. The old WDK allowed you to build some applications, but it was getting increasingly crufty. @R0b0t1: In terms of how you figure all this out... I grant you there's an inordinate amount of documentation that directs you to use VS for all things... including deployment and test machines and debugging. But how to setup debugging manually IS pretty well documented now (it took about 15 years to get it all written up clearly... no joke). And there's really very little way for somebody who's not already a community member to know that a lot of the VS integrated deploy/test/debug stuff just doesn't work. Because, it doesn't. For every version of the "push a button to run driver tests" (you know, setting up test machines, and automatic deployment and such)... I've had the PM tell me "THIS version works. Really!" and when the NEXT version is ready to ship they said "Yes, we realize that the PREVIOUS version DID NOT WORK. AT ALL. Completely broken. But I SWEAR to you, this next version works." Rinse and repeat. I don't know how a new dev comes to learn that... but that's the computer industry for you. In fairness: I HAVE NOT TRIED THIS FEATURE IN THE RS3 WDK YET. Maybe it works great now. The dev who owns this feature is clever, and really wants to make it work. SO, maybe the third time is a chamr? 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 28 of 38  
12 May 17 20:36
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 744
Visual Studio debug breakpoints not hit

I routinely use both. And sometimes even at the same time on the same issue. VS has a lot of code browsing and searching features that WinDbg lacks, but VS lacks some of the key debugging extensions that WinDbg has. Even when live debugging, it is easy enough to generate a crashdump from one to open in the other for additional analysis. I do wish that the VS team would resolve these issues (or someone with more free time than me would on their behalf), but I would rather that they start with fixing the compiler code analysis features and the cross language dependency graph problems first. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: xxxxx@outlook.com<mailto:xxxxx@outlook.com> Sent: May 12, 2017 3:50 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE: [ntdev] Visual Studio debug breakpoints not hit Actually a second instance of VS used for debugging a target consumes only 10 to 15 more MB than WinDbg. So if you prefer VS,use VS and if you prefer WinDbg, use WinDbg. There isn=92t any difference. W. N. --- 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 29 of 38  
15 May 17 08:47
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> I'm still waiting for the VS team to fix the code analysis features they broke by "modernizing: the compiler for VS2015. </quote> Me too. It looks to ME like the majority of cases where we're missing CA hits is on driver-specific rules. If somebody had the time to explore and write-up a description of what's missing and what's not working consistently, I *know* the WDK team would be *very* willing to pursue this. Normally this is the kind of thing we'd do here at OSR for the community. But I'm afraid we've been pretty busy, and don't have the bandwidth for this project right now. Peter OSR @OSRDrivers
  Message 30 of 38  
15 May 17 12:47
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Visual Studio debug breakpoints not hit

Apropos of nothing: VS2017 does not currently support driver development. Perhaps the whole integration with VS thing was a mistake? I tried to get an actual answer from assorted VS people at build but they all pointed at somebody else and ran away. Didn't leave me with a warm and comfy feeling about where things are headed. Doron? Mark Roddy On Fri, May 12, 2017 at 5:35 PM, Marion Bond <xxxxx@hotmail.com> wrote: > I routinely use both. And sometimes even at the same time on the same > issue. > > > > VS has a lot of code browsing and searching features that WinDbg lacks, > but VS lacks some of the key debugging extensions that WinDbg has. Even > when live debugging, it is easy enough to generate a crashdump from one to > open in the other for additional analysis. > <...excess quoted lines suppressed...> --
  Message 31 of 38  
15 May 17 15:36
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 53
Visual Studio debug breakpoints not hit

On Mon, May 15, 2017 at 11:46 AM, Mark Roddy <xxxxx@hollistech.com> wrote: > Apropos of nothing: VS2017 does not currently support driver development. > Perhaps the whole integration with VS thing was a mistake? I tried to get= an > actual answer from assorted VS people at build but they all pointed at > somebody else and ran away. Didn't leave me with a warm and comfy feeling > about where things are headed. > > Doron? > > Mark Roddy > This is something that colored my view on using VS for driver development - it looks like half of the effort necessary to get VS to support all features was put forth, and at the same time some features were retracted from the previous workflow. So now there's two incomplete and mostly incompatible options. > On Fri, May 12, 2017 at 5:35 PM, Marion Bond <xxxxx@hotmail.com> wro= te: >> >> I routinely use both. And sometimes even at the same time on the same >> issue. >> >> >> >> VS has a lot of code browsing and searching features that WinDbg lacks, >> but VS lacks some of the key debugging extensions that WinDbg has. Even >> when live debugging, it is easy enough to generate a crashdump from one = to >> open in the other for additional analysis. >> >> >> >> I do wish that the VS team would resolve these issues (or someone with >> more free time than me would on their behalf), but I would rather that t= hey >> start with fixing the compiler code analysis features and the cross lang= uage >> dependency graph problems first. >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: xxxxx@outlook.com >> Sent: May 12, 2017 3:50 PM <...excess quoted lines suppressed...> ly >> 10 to 15 more MB than WinDbg. >> >> >> >> So if you prefer VS,use VS and if you prefer WinDbg, use WinDbg. There >> isn=E2=80=99t any difference. >> >> >> >> W. N. on > crash dump analysis, WDF, Windows internals and software drivers! Details= at > To unsubscribe, visit the List Server section of OSR Online at
  Message 32 of 38  
15 May 17 20:41
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 744
Visual Studio debug breakpoints not hit

Peter I don?t know which ones you see most commonly, but the ones that I see most often fall into the following catergories 1. Static variables. These are never handled correctly by CA regardless of the scope of their declaration. If they are declared at function scope, then CA crapps out on the remainder of the function. It may seem odd that this is even an issue, because just like goto many will say ?don?t do that? but static variables have some important usages especially in debug / trace code (I.e. call counts etc.) and I believe it is better to have the analysis on for every build to catch issues as early as possible ? which means running it with the trace code 2. Flow of control based on multiple dependent variables. Where loop counters etc. are not independent variables are not independent, it is easy to observe many false positives for impossible array out of bounds conditions etc. Again it is easy to say, don?t do that, but for performance reasons it is often highly desirable to store a result from a previous loop or use a co-dependent set of counters. It seems clear that when evaluating the graph of every possible program state within a function, dependent variables are not considered concurrently but rather each variable is assumed to be independent ? a clear problem for false positives for codependent loop counters etc. but even worse a clear source of false negatives for aliased pointers. 3. Reference tracking algorithms. Where in box from MS or home grown, the semantics are fundamentally not supported by SAL and so produce a long series of false positives and worse false negatives. The acquire routines work out okay, but the release routines are always a problem 4. Locking annotations seem completely broken. I still annotate my functions because I want to understand the constraints, but I always get errors that look like this that I am completely unable to resolve Severity Code Description Project File Line Suppression State Warning C26135 Missing annotation _Acquires_lock_(pQueue->cs) at function 'QUEUE_Lock'. CORE c:\aprg\fix platform\src\lib\core\queue\queue.h 376 Active ///////////////////////////////////////////////////////////////////////////////// _Acquires_lock_(pQueue->cs) __inline void QUEUE_Lock(_In_ QUEUE* const pQueue) { #ifdef _DEBUG if(!pQueue->bLock) { DebugBreak(); } #endif EnterCriticalSection(&pQueue->cs); } 1. Functions declared in header files never work either. Moving the code into a .c file is a workaround, but sometime you want a routine to be inline compiled I have lost count of all of the specific issues, but these ones are certainly present. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: xxxxx@osr.com<mailto:xxxxx@osr.com> Sent: May 15, 2017 8:48 AM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Visual Studio debug breakpoints not hit <quote> I'm still waiting for the VS team to fix the code analysis features they broke by "modernizing: the compiler for VS2015. </quote> Me too. It looks to ME like the majority of cases where we're missing CA hits is on driver-specific rules. If somebody had the time to explore and write-up a description of what's missing and what's not working consistently, I *know* the WDK team would be *very* willing to pursue this. Normally this is the kind of thing we'd do here at OSR for the community. But I'm afraid we've been pretty busy, and don't have the bandwidth for this project right now. 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 33 of 38  
15 May 17 21:15
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

<quote> VS2017 does not currently support driver development. ... Perhaps the whole integration with VS thing was a mistake? I tried to get an actual answer from assorted VS people at build but they all pointed at somebody else and ran away. </quote> Of course they did. You're asking the wrong people. The VS people work in dev div... they have nothing to do with creating the WDK. The WDK is over in Windows with the cool kids. I was told that the WDK doesn't support VS 2017 due to the changes in how the two need to be integrated. I was assured by the dev kits team that lack of support for VS 2017 in the RS 2 WDK was a timing and a resource issue. If your question is "Will there be a reversal of support for the WDK's integration with VS" I can tell you that I'm not hearing anything at all like that. The integrated WDK is widely viewed as a major win, and i can't imagine it going back.I If your question is "Why aren't there sufficient resources available for the kits team to build the WDK, so that it could properly support VS 2017 at launch"... I think that's a reasonable question. I think the answer is that we driver devs just aren't a priority these days. Which makes me sad. Peter OSR @OSRDrivers
  Message 34 of 38  
15 May 17 21:22
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

Thank you, Mr. M M... I haven't seen all those myself, but I've been driven nuts trying to get the locking annotations working, much like you describe. A timing this point, add locking annotations is largely an article of faith coupled with an exercise in frustration. Drives me nuts. It's too bad, too... because those locking annotations are really some of the best and most useful annotations. Potentially very impactful on a code base. Peter OSR @OSRDrivers
  Message 35 of 38  
15 May 17 22:38
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Visual Studio debug breakpoints not hit

Just to allay any misplaced fears... the latest Windows Insider Program (early release) of the WDK supports VS 2017. Anyone can join the Windows Insider program, and download it. Foto: <https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewWDK> It IS a prerelease, so .... beware. But it should at least demonstrate that a VS 2017 compatible WDK is already in the works. Peter OSR @OSRDrivers
  Message 36 of 38  
16 May 17 10:39
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2401
Visual Studio debug breakpoints not hit

> the latest Windows Insider Program (early release) of the WDK supports VS 2017. One of cool features in VS2017 is support of CMake. And this actually opens a way to resurrect SOURCES - style driver projects as CMake projects, if a special generator would exist :) Anyone wants to try? :) -- pa
  Message 37 of 38  
16 May 17 13:59
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11663
Visual Studio debug breakpoints not hit

xxxxx@osr.com wrote: > If your question is "Why aren't there sufficient resources available for the kits team to build the WDK, so that it could properly support VS 2017 at launch"... I think that's a reasonable question. I think the answer is that we driver devs just aren't a priority these days. Which makes me sad. Well, driver devs have never been a priority, and it's hard to argue with that decision. There are too few of us to make a business case for priority treatment. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 38 of 38  
16 May 17 18:54
M M
xxxxxx@hotmail.com
Join Date: 21 Oct 2010
Posts To This List: 744
Visual Studio debug breakpoints not hit

I agree completely ? the buffer overrun stuff is very useful (and should work a lot better seeing as it is all statically determinant behaviour), but the most difficult bugs to find are the non-deterministic ones that the locking annotations are designed to reveal. I understand that the ref-counting paradigm is particularly difficult for a compiler to evaluate, but the basic _Interlocked_ and acquire / release semantics should be straightforward. For debug builds I have implemented a runtime trace solution to reference tracking bugs, but at compile time, it would be nice if there were annotations to describe the pointer reference assumptions. In fact I wrote some prototype code to look at this when I was looking at writing my own code to check the SAL instead of the MS compiler, but I don?t really have the time to complete this Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: xxxxx@osr.com<mailto:xxxxx@osr.com> Sent: May 15, 2017 9:22 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Visual Studio debug breakpoints not hit Thank you, Mr. M M... I haven't seen all those myself, but I've been driven nuts trying to get the locking annotations working, much like you describe. A timing this point, add locking annotations is largely an article of faith coupled with an exercise in frustration. Drives me nuts. It's too bad, too... because those locking annotations are really some of the best and most useful annotations. Potentially very impactful on a code base. 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 04:23.


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