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
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
@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?
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:</https:>
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
On Wed, May 10, 2017 at 3:12 PM, wrote:
>
>
> 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:</https:>
>
> 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
>
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.
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
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
> Subject: RE:[ntdev] Visual Studio debug breakpoints not hit
>
>
>
> 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:> studio-integration-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
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:></https:>
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
> Subject: RE: RE:[ntdev] 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
> > Subject: RE:[ntdev] Visual Studio debug breakpoints not hit
> >
> >
> >
> > 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:> > studio-integration-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
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list online at:
> > http:
> >
> > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> > software drivers!
> > Details at http:
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http:
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:></http:></http:></http:></https:>
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
> 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…
>
> /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
> > Subject: RE: RE:[ntdev] 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
> > > Subject: RE:[ntdev] Visual Studio debug breakpoints not hit
> > >
> > >
> > >
> > > 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:> > > studio-integration-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
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > Visit the list online at:
> > > http:
> > >
> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> > > software drivers!
> > > Details at http:
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http:
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list online at:
> > http:
> >
> > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> > software drivers!
> > Details at http:
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http:
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:></http:></http:></http:></http:></http:></http:></https:>
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
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.
Sorry, I meant ? two instances ? and not ? to instances ?
W. N.
De : xxxxx@outlook.commailto:xxxxx
Envoy? le :jeudi 11 mai 2017 17:13
? : Windows System Software Devs Interest Listmailto:xxxxx
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:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx>
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.
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
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).
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.
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
« Visual Studio debug breakpoints not hit »
With the humble but very powerful WinDbg, this would be as easy as :
bp Mydriver!Myfunction
J. S.
On Thu, May 11, 2017 at 12:30 PM, Bo Branten 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:
>
> 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
>
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.
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.
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
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
Visit the list online at:
http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:>
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.