Testing driver with verifier

Hi,
Firstly, I hope I am posting on the correct list. I was not sure I should post here or on NTDEV list.
I’ve read the article named “Analyst?s Perspective: My Driver Passes Driver Verifier!” and I am trying to have verifier configured perfectly with my vs 2013 project for a file system minidriver.
I have configured ‘deployment’ and ‘driver verification’ tabs under ‘driver install entry’. They work and I detected some new bugs using verifier. Then I’ve added fltmgr.sys to verifier as well and it resulted in more bugs showing.
My question is about the tabs next to ‘driver verification’, KMDF and UMDF verifier.
Since I’m rather new to kernel development (1-2 month experience on minifilters) I doubt if:

  1. my minidriver lays in the same category with KMDF or UMDFs?
  2. I need to enable KMDF and/or UMDF verifier to get better results as well?
  3. Is there any other configuration to get the full advantage of verifier to detect my driver bugs? (like any other driver to add to the verifier list beside fltmgr and my own driver)

xxxxx@yahoo.com wrote:

Firstly, I hope I am posting on the correct list. I was not sure I should post here or on NTDEV list.
I’ve read the article named “Analyst?s Perspective: My Driver Passes Driver Verifier!” and I am trying to have verifier configured perfectly with my vs 2013 project for a file system minidriver.
I have configured ‘deployment’ and ‘driver verification’ tabs under ‘driver install entry’. They work and I detected some new bugs using verifier. Then I’ve added fltmgr.sys to verifier as well and it resulted in more bugs showing.
My question is about the tabs next to ‘driver verification’, KMDF and UMDF verifier.
Since I’m rather new to kernel development (1-2 month experience on minifilters) I doubt if:

  1. my minidriver lays in the same category with KMDF or UMDFs?

A file system minidriver cannot be in user mode, so you can’t be UMDF.
Is your driver a KMDF driver? Are you using WdfDriverCreate and
WdfDeviceCreate and the other KMDF APIs? I suspect you are not. And if
not, then you aren’t a KMDF driver, either

  1. I need to enable KMDF and/or UMDF verifier to get better results as well?

The KMDF verifier only checks KMDF drivers. If you aren’t KMDF, then
you don’t need the verifier. Same for UMDF.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

The basic idea is that Verifier doesn’t automatically verify modules that
you import from. So, if you import any APIs from any other module you
(generally) want to enable Verifier on the other modules as well.

If you’re a minifilter FltMgr.sys is a good place to start. You can also
enable Verifier on ntoskrnl.exe if you’re directly calling any APIs from the
NT module. This can have a bit of a perf cost, so I usually only do that
every once in a while.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

Hi,
Firstly, I hope I am posting on the correct list. I was not sure I should
post here or on NTDEV list.
I’ve read the article named “Analyst?s Perspective: My Driver Passes Driver
Verifier!” and I am trying to have verifier configured perfectly with my vs
2013 project for a file system minidriver.
I have configured ‘deployment’ and ‘driver verification’ tabs under ‘driver
install entry’. They work and I detected some new bugs using verifier. Then
I’ve added fltmgr.sys to verifier as well and it resulted in more bugs
showing.
My question is about the tabs next to ‘driver verification’, KMDF and UMDF
verifier.
Since I’m rather new to kernel development (1-2 month experience on
minifilters) I doubt if:

  1. my minidriver lays in the same category with KMDF or UMDFs?
  2. I need to enable KMDF and/or UMDF verifier to get better results as well?
  3. Is there any other configuration to get the full advantage of verifier to
    detect my driver bugs? (like any other driver to add to the verifier list
    beside fltmgr and my own driver)

Thans Tim. Thanks scott.

Is your driver a KMDF driver? Are you using WdfDriverCreate and
WdfDeviceCreate and the other KMDF APIs? I suspect you are not. And if
not, then you aren’t a KMDF driver, either

I don’t. so I’m not.

If you’re a minifilter FltMgr.sys is a good place to start. You can also
enable Verifier on ntoskrnl.exe if you’re directly calling any APIs from the
NT module. This can have a bit of a perf cost, so I usually only do that
every once in a while.

I asked for any other consideration in testing. Thanks for your explanation scott.
In these 2-3 days a searched and read MSDN and google about this matter. MSDN suggests many more testing procedures like:
testing against checked build version of windows while having verifier on
and
code analysis and static test using Visual studio

The link is here:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff552872(v=vs.85).aspx

my question is: do you consider all these steps in development? and how important they are?

I went back and read your original post. You specifically asked about
Verifier and not about other considerations in testing.

That being said, the tools mentioned on that site are all very important for
driver development. You should enable Code Analysis (with all rules) to run
on every build of your driver. You should run Static Driver Verifier
regularly (also with all rules) and resolve any issues.

The checked build is also useful as it catches unique problems. Running an
entire checked build is generally considered painful, we mostly stick to a
partial checked build to get most of the benefit with minimum pain:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff547188(v=vs.85).aspx

If you’re writing a minifilter, you should also run with a checked copy of
FltMgr.sys. You can take the version from the checked build and simply
replace the existing file (or change the ImagePath value in the registry,
which is what I usually do so that I can easily go back).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@windbg…

Thans Tim. Thanks scott.

Is your driver a KMDF driver? Are you using WdfDriverCreate and
WdfDeviceCreate and the other KMDF APIs? I suspect you are not. And if
not, then you aren’t a KMDF driver, either

I don’t. so I’m not.

If you’re a minifilter FltMgr.sys is a good place to start. You can also
enable Verifier on ntoskrnl.exe if you’re directly calling any APIs from the
NT module. This can have a bit of a perf cost, so I usually only do that
every once in a while.

I asked for any other consideration in testing. Thanks for your explanation
scott.
In these 2-3 days a searched and read MSDN and google about this matter.
MSDN suggests many more testing procedures like:
testing against checked build version of windows while having verifier on
and
code analysis and static test using Visual studio

The link is here:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff552872(v=vs.85).aspx

my question is: do you consider all these steps in development? and how
important they are?

> I went back and read your original post. You specifically asked about
Verifier and not about other considerations in testing.

Sorry about that. I was not aware of any other option then.

The checked build is also useful as it catches unique problems. Running an
entire checked build is generally considered painful, we mostly stick to a
partial checked build to get most of the benefit with minimum pain:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff547188(v=vs.85).aspx

I had problem running the partially checked build as well. could you please have a look at my other question concerning it?