The toaster sample drivers are all plug and play which OSRLOADER does not
support. You are going to have to use the INF file with either device
manager or devcon to load the driver.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@claessen.com
xxxxx@lists.osr.com
Sent: Tuesday, August 22, 2017 3:59 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] MS Toaster sample driver blue-screens on me …
Greetings,
I’m having some Windows driver BSOD issues and I’m looking for suggestions.
I’m working on a Windows 7 (64 bit) PC. I’m using VS2015 and WDK-10.
I used VS2015 to write a very minimal driver (debug - x64): it basically is
just a “DriverEntry” and a “DriverUnload” function, only doing some
DbgPrints. I built it (test signed it, and running Windows 7 in Test Mode),
I used OSRLOAD to register and load it, and everything works fine. I can
load and unload it at will, and I see my DbgPrints in DebugView.
So far so good.
Then I wanted to add some more functionality and found the famous WDK
‘Toaster’ driver sample source.
So, I decided to first build that, and then study it.
I used the provided solution file, and I built the project wdfSimple.
I used the same set-up as above, the ONLY things I changed were a) I added
test-signing certifcate data to the properties, and changed the default
setting from debug-x32 to debug-x64.
It built fine! But when I use OSRLOAD to load it (after registering it), it
bluescreens.
Since I’m not yet on a 2 machine develop-test set-up (I just wanted to do
some quick tests), and thus can’t debug it well, I simply started trimming
it down to see what caused the bluescreen (I know, not a very professional
procedure).
It kept dying on me. So at last I simply commented ALL code out in my
toaster.c and pasted the code, that worked just fine in my own minimal
driver. Built it, signed it, loaded … and it bluescreens as well! Same
code!
I have been comparing project properties and nothing jumps out to me as
being different between the projects. The generated .sys files have both the
exact same number of bytes (in their ‘data’ section).
I uploaded the minidump to OSR’s analyzer and it tells me the following,
basically suggesting there’s a break point being set.
“
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e) This is a very common
bugcheck. Usually the exception address pinpoints the driver/function that
caused the problem. Always note this address as well as the link date of
the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard coded
breakpoint or assertion was hit, but this system was booted /NODEBUG.
”
I have no breakpoints set, VS2015 has ‘delete all breakpoints’ grayed out,
and the address of where the violation occurs (602d) is way outside the
memory used by my driver, based on the link map I had it generate for this
purpose.
So it really looks my code is stomping on something it shouldn’t be
accessing.
I’m out of ideas … and I’m also wondering: Why can’t I build and run the
‘toaster’ sample driver, as is, out of the box? It must, surely, have been
built by tens of thousands of people! Can’t find anything with Google on a
blue-screening toaster sample driver either!
It MUST be something in the build procedure/project properties, because the
source code is now identical between ‘my’ toaster.c and my little minimal
driver that works just fine.
Somehow this feels like it’s something simple, but I can’t think of
anything.
Any ideas will be very very welcome.
~ Paul Claessen
—
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:>