Hi Folks,
Any one help me here.
I downloaded entire checked build of Win10 OS version 1511, where i can find the debug version of NDIS.sys driver file.
Thanks,
Hi Folks,
Any one help me here.
I downloaded entire checked build of Win10 OS version 1511, where i can find the debug version of NDIS.sys driver file.
Thanks,
As a general rule, you canât install the checked version of a single driver. You need to install the whole checked system.
As another general rule, the checked systems arenât very useful. What are you hoping to find? And, from a higher level, what kind of a driver are you planning to write?
@Tim_Roberts said:
As a general rule, you canât install the checked version of a single driver. You need to install the whole checked system.
Why not ? Thatâs what we doing when debugging our own drivers. So unless you talking about closely coupled modules like nt and hal it is totally ok to use checked version of driver on release system.
As another general rule, the checked systems arenât very useful. What are you hoping to find?
Additional asserts definitely can be helpful.
Thank you for the replies.
I am trying to write virtual NDIS miniport driver. I downloaded the entire Win10 OS checked build from MSDN subscription not just any single driver. To get more understanding of the NDIS framework I wanted to enable the NDIS tracing as mentioned in the MSDN page. But when i run the command to enable tracing ândiskd.dbgsystemsâ it throws error.
!ndiskd.dbgsystems
This target does not support tracing through !ndiskd.dbglevel or
!ndiskd.dbgsystems.
Learn how to collect traces with WPP
Then i checked whether i am running free or checked OS in the Windbg output, it says the operating system is checked OS as shown below.
âWindows 10 Kernel Version Checked x64â.
I am sure the OS is checked build as i see some assertion getting failed. But couldnât enable NDIS tracing. Please help me.
As a general rule, you canât install the checked version of a single driver. You need to install the whole checked system.
As another general rule, the checked systems arenât very useful. What are you hoping to find? And, from a higher level, what kind of a driver are you planning to write?
With all due respect to my colleague Mr Roberts, I donât agree with either of these assertions.
Installing just the checked build of various system components â if and when you can find them â has always worked. You can install just the checked kernel and HAL, or even just the checked version of NTFS.SYS or all the drivers in the storage stack. The checked build is just the âdebugâ flavor of the driver, after all, and doesnât require any special support from the OS (anymore than running the debug build of your own driver does).
The extra checking provided by the checked/debug build can be very helpful is finding otherwise difficult problems. There is often (more, additional) logging in the checked drivers thatâs not in the release build.
Having said that, I agree that using the checked build has gone âout of styleâ over the past number of years. Running your drivers on the checked build before release USED TO be a best practice. Now, the checked build of anything is so hard to find, itâs barely done anymore. And, because of that, I suspect the MSFT devs are less likely these days to add cool, value-added checking in the checked builds of their code. All this combines to make using the checked build something thatâs rarely done these days. We regularly release code that has never been run on a checked build of the OS. Even five years ago, that would have been a heresy.
Peter
Hi Peter,
What is the best way to get detailed tracing of the Microsoft internal NDIS driver if checked build of the OS is not a good option?
Well⌠Iâm not an NDIS person, so I donât know.
I do know that you ARE apparently already running the checked build of the OS⌠and when you install âthe entire Win10 OS checked build from MSDN subscriptionâ you install the checked OS image, the checked HAL, and all the checked drivers (and applications, even).
So, Iâd say you already are running the checked build of the drivers. Sorry I didnât see this in your initial post.
Peter
Even though i am running Win10 checked OS i am not seeing any NDIS messages and first of all could not enabled NDIS tracing as per MSDN page. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-ndis-debug-tracing
Did you read about collecting WPP traces, as the output you quoted says?
Like I said⌠Iâm not an NDIS guy, but I can read.
Peter
Pardon the offtopic, but how did you get the Checked build, and even
more importantly, how did you get it to install?
There is only one Checked build of W10 on MSDN (1511) and I know of
noone who was able to install it to dateâŚ
âWindows 10 Kernel Version Checked x64â.
The WPP trace info is in the NDIS pdb symbol file on Windows 10. I think the .tmf files can be extracted from it, but that shouldnât be needed. (The checked build also isnât needed for WPP logging.)
In WinDbg run
!wmitrace.start ndis -kd
!wmitrace.enable ndis {DD7A21E6-A651-46D4-B7C2-66543067B869} -level 4 -flag 0x31f3
as per https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-ndiskd-dbgsystems
If only âNo Format Information foundâ messages are displayed, sometimes I find running !wmitrace.logdump ndis
fixes it. As ever with WPP, YMMV.
It should also be possible view the messages by loading the correct ndis.pdb in TraceView. I havenât often, however, found NDIS logging to be that useful with the issues Iâve tried using it to look into.
Hi Dejan_Maksimovic,
Even i encountered lot of failure from BIOS or EFI or after installing the Windows, it says critical system process failed. But somehow i am able to make it to boot successfully. Definitely Microsoft people has to take a look why Win10 1511 debug version is failing, instead of everyone wasting our time.
Definitely Microsoft people has to take a look why Win10 1511 debug version is failing, instead of everyone wasting our time.
That release is more than 4 years old. Thanks to the new aggressive update philosophy, almost no one in the real world is running that build, and youâre not going to find anyone in Redmond interested in looking at it.
True
Now i am running WMI tracing what mksp mentioned in his reply. I am seeing some of the NDIS tracing.
The WPP trace info is in the NDIS pdb symbol file on Windows 10. I think the .tmf files can be extracted from it, but that shouldnât be needed. (The checked build also isnât needed for WPP logging.)
Yup. As of Windows 8, NDIS.PDB from the public symbol server has the TMF files literally embedded in it. If you need to see them, tracepdb.exe can extract them. But you donât usually need to see them; most WPP tools understand how to get the TMFs from the PDB automatically. If youâre still using Windows 7, see this page: https://docs.microsoft.com/en-us/archive/blogs/ndis/tmf-download-page
. . . checked build . . .
You can definitely place a CHK version of NDIS.SYS onto an ordinary FRE operating system. I do most of my day-to-day testing by doing exactly that. (.kdfiles is awesome!) However, as Mr Viscarola says, thereâs actually not a big difference between FRE and CHK anymore. In very old versions of NDIS (Windows XPâŚ), you needed to use the CHK version to activate much of the debugging functionality. But more recently, and certainly with Windows 10, most of the debugging features work just fine with a FRE version. There are a few ancient old debugger commands like !ndiskd.mem that still require CHK, I think, but those commands arenât very useful anymore.
Far more importantly: enable Driver Verifier with the NDIS/WIFI flag. Enable this on at least your driver and NDIS.SYS. You may need WDIWIFI.SYS and/or NETADAPTERCX.SYS if youâre using those. In a few cases, itâll also help to enable it on TCPIP.SYS and NETIO.SYS, although thatâs usually not necessary. Enabling it on the entire system is the easiest thing to do, although itâll slow things down noticeably.
These days, the CHK version of NDIS is mostly geared towards verifying the correctness of NDIS.SYS itself, so itâs mostly there for the Microsoft team to use. Driver Verifier is geared towards verifying the correctness of 3rd party drivers, so itâs for you.
Thanks Jeffery for the most valuable inputs. Really appreciate it.