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.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 6  
29 Jan 18 14:19
Ben Westbrook
xxxxxx@propellerhead.net
Join Date: 29 Jan 2018
Posts To This List: 1
storport.sys source project

I read somewhere that the source code for storport.sys, including the code for the windows 10 version, was available for driver developers to assist in writing new storage drivers. Finding that little nugget again feels as if I am looking for a needle in a field of haystacks. Can you help me locate that project please?
  Message 2 of 6  
31 Jan 18 02:01
Gabriel Bercea
xxxxxx@gmail.com
Join Date: 03 Mar 2008
Posts To This List: 133
storport.sys source project

If it is not here[1] I doubt you will find it somewhere else. Cheers, Gabriel www.kasardia.com [1] https://github.com/Microsoft/Windows-driver-samples/tree/master/storage On Mon, Jan 29, 2018 at 8:19 PM, xxxxx@propellerhead.net <xxxxx@lists.osr.com> wrote: > I read somewhere that the source code for storport.sys, including the code > for the windows 10 version, was available for driver developers to assist > in writing new storage drivers. Finding that little nugget again feels as > if I am looking for a needle in a field of haystacks. Can you help me > locate that project please? > > --- > NTDEV is sponsored by OSR > > Visit the list online at: <http://www.osronline.com/ <...excess quoted lines suppressed...> -- Bercea. G. --
  Message 3 of 6  
31 Jan 18 03:12
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 432
storport.sys source project

When I worked at one of the largest computer vendors a few years ago, a small number of us did have Windows source code access. You did almost have to sign your life away in the NDA. Having source access was occasionally moderately useful, but not as useful as one might think. Just finding the correct location in 80 million lines of code was often a major adventure. We also didn't get the source code in a form you could modify or build. In hindsight, I'm not sure there were any debugging problems I was able to solve with source code access that I could not have solved, with more effort and time, without source code access. Being very comfortable digging though assembler helps a lot, as does fast single stepping (1394 transport). Not so long ago, I was working for a very large vendor of storage controller chips, which had a number of Windows kernel developers, and they did not have direct access to storport source code, although did have an employee who had good technical support contacts inside Microsoft. The Microsoft policy on source code access has varied over the years. At one point all you needed was 10,000 Windows seats in your company, and you could get read access to the source code for debugging purposes. At the other end of the scale, many years ago, Microsoft gave a select few individual MVP kernel developers source access. I'm not sure what the official policy is today, but unless you work at a mega corporation that owns or sells a lot of copies of Windows (or you work at Microsoft, on the correct team), source access is likely not available. Jan -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@propellerhead.net Sent: Monday, January 29, 2018 11:19 AM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: [ntdev] storport.sys source project I read somewhere that the source code for storport.sys, including the code for the windows 10 version, was available for driver developers to assist in writing new storage drivers. Finding that little nugget again feels as if I am looking for a needle in a field of haystacks. Can you help me locate that project please? --- 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 4 of 6  
04 Feb 18 13:58
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4087
storport.sys source project

Well my experience was just the opposite. Having source code access was immensely valuable and saved many hours of debugging time on many problems. You of course need to understand the source code organization, as indeed otherwise blindly searching 80 million lines of code every time you needed to figure something out would be horrible. Also note that windbg is happy to point one at the source code for stackframes if you have the pdb files and the source code. Mark Roddy On Wed, Jan 31, 2018 at 3:12 AM, xxxxx@pmatrix.com <xxxxx@lists.osr.com > wrote: > When I worked at one of the largest computer vendors a few years ago, a > small number of us did have Windows source code access. You did almost have > to sign your life away in the NDA. Having source access was occasionally > moderately useful, but not as useful as one might think. Just finding the > correct location in 80 million lines of code was often a major adventure. > We also didn't get the source code in a form you could modify or build. > > In hindsight, I'm not sure there were any debugging problems I was able to > solve with source code access that I could not have solved, with more <...excess quoted lines suppressed...> --
  Message 5 of 6  
04 Feb 18 23:13
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 1068
storport.sys source project

In the past I was able to see windows kernel sources ( outside Microsoft), but it was only for browsing. Don???t know or care much about the licensing, but having symbol files is way better than gleaning thru the sources, and figure out what???s going on. But I guess, it is just a little help just in case understand what is going on in a specific area of the kernel - related to the problem being observed. Whereas, in Apple Platform, stepping thru the kernel to vendor specific code is fairly easy - though the native debugger is not as powerful as Windbg. -Pro > On Feb 4, 2018, at 10:57 AM, xxxxx@gmail.com <xxxxx@lists.osr.com> wrote: > > Well my experience was just the opposite. Having source code access was immensely valuable and saved many hours of debugging time on many problems. You of course need to understand the source code organization, as indeed otherwise blindly searching 80 million lines of code every time you needed to figure something out would be horrible. Also note that windbg is happy to point one at the source code for stackframes if you have the pdb files and the source code. > > > > Mark Roddy > > On Wed, Jan 31, 2018 at 3:12 AM, xxxxx@pmatrix.com <mailto:xxxxx@pmatrix.com> <xxxxx@lists.osr.com <mailto:xxxxx@lists.osr.com>> wrote: > When I worked at one of the largest computer vendors a few years ago, a small number of us did have Windows source code access. You did almost have to sign your life away in the NDA. Having source access was occasionally moderately useful, but not as useful as one might think. Just finding the correct location in 80 million lines of code was often a major adventure. We also didn't get the source code in a form you could modify or build. <...excess quoted lines suppressed...> --
  Message 6 of 6  
08 Feb 18 14:51
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6150
List Moderator
storport.sys source project

There's been quite a bit of thread drift here. Be that as it may... Mr. Roddy wrote: <quote> Well my experience was just the opposite. Having source code access was immensely valuable and saved many hours of debugging time on many problems. </quote> This. I'll never forget the first day I had access to the Windows source code. The first task I set for myself was to discover why you had to both call IoMarkIrpPending AND return STATUS_PENDING from your dispatch entry point. I figured it'd take me a couple of hours, and this was something I *always* wanted to understand. It took me two years to answer that question. And probably another two years to fully appreciate the consequences of that answer. Seriously. The Windows source code is just like any really large and really complex code base: it's super easy to get lost looking for what you think is a simple answer to a simple question. The code is naturally full of acronyms, abbreviations, and technical details. It's not designed for learners. Not to mention, the overall source code base spans a large number of very different technical disciplines. You have to know *a lot* about how each piece of Windows works (what features are provided and how those features can be used) before you can understand how that piece is implemented. The journey, to me at least, was totally worth it. Peter OSR @OSRDrivers
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 15:46.


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