DDK for "installable drivers"?

NTDEV
1

How can I build a windows multimedia “installable driver”
(http://msdn2.microsoft.com/en-us/library/ms709319.aspx) that doesn’t
crash when I call OpenDriver on it?

Steps I took were:
* downloaded the Windows Server 2003 DDK ISO from
http://www.microsoft.com/whdc/devtools/ddk/default.mspx.
* burnt a CD from it and installed it
* built default DLL project in Visual Studio
* created DriverProc entry point as the docs described
* called OpenDriver on the new module from a test app

Unfortunately the app crashes inside windows on return. I suspect it has
to do with calling conventions but poking around in the dark.

So, questions:
* did I get the right DDK for building drivers for regular folks who are
using win xp?
* do I need to build my DLL with the Windows DDK build tools?
* can I use something like DDKBUILD and integrate the DDK build in to
Visual Studio .NET?
* if can I use the Visual Studio compiler for this kind of project, any
clues about what settings to use?

I guess I am not sure how much of a “real driver” these installable
drivers actually are…? And I can’t find anything in the MSDN
documentation about how to actually compile and link one of these things.

Any help or tips would be greatly appreciated.

  • Michael Ost

PS: if it helps clarify, output from visual studio…

Debug output:
First-chance exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005:
Access violation reading location 0x00000017.
First-chance exception at 0x7c812a5b in Boomwhacker.exe: Microsoft C++
exception: [rethrow] @ 0x00000000.
Unhandled exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005: Access
violation reading location 0x00000017.

Call stack at the crash:
ntdll.dll!7c901010()
winmm.dll!76b42e8e()
winmm.dll!76b42e53()

Boomwhacker.exe!BoomwhackerApp::OnInit() Line 29 + 0x11 C++

2

Michael Ost & Martha Wade wrote:

How can I build a windows multimedia “installable driver”
…
Unfortunately the app crashes inside windows on return. I suspect it has
to do with calling conventions but poking around in the dark.

Why are you in the dark? The declaration of DriverOpen, including the
calling convention, is in mmsystem.h.

So, questions:
* did I get the right DDK for building drivers for regular folks who are
using win xp?

Yes, but the DDK is not required to build a multimedia installable
driver. Just about everything you need is in mmsystem.h in the standard
SDK.

* do I need to build my DLL with the Windows DDK build tools?

No.

* can I use something like DDKBUILD and integrate the DDK build in to
Visual Studio .NET?

You can use Visual Studio without DDKBUILD. It is just a plain,
ordinary, user-mode DLL.

* if can I use the Visual Studio compiler for this kind of project, any
clues about what settings to use?

The only thing to double-check is that DriverProc is declared CALLBACK,
which means __stdcall. The DDK defaults to __cdecl.

I guess I am not sure how much of a “real driver” these installable
drivers actually are…?

I don’t know what makes a “real driver”. These aren’t kernel drivers,
but most apps can’t tell the difference.

Debug output:
First-chance exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005:
Access violation reading location 0x00000017.
First-chance exception at 0x7c812a5b in Boomwhacker.exe: Microsoft C++
exception: [rethrow] @ 0x00000000.
Unhandled exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005: Access
violation reading location 0x00000017.

Call stack at the crash:
ntdll.dll!7c901010()
winmm.dll!76b42e8e()
winmm.dll!76b42e53()
> Boomwhacker.exe!BoomwhackerApp::OnInit() Line 29 + 0x11 C++


Acting as a symbol server, that’s ntdll!RtlEnterCriticalSection+0xb,
winmm!InternalOpenDriver+0x32, winmm!DrvOpen+0x15. It crashed early in
RtlEnterCriticalSection, grabbing a lock from the thread block at fs:0.
It sure looks like a stack smash. Can you show us the declaration of
and the code in your DllEntryPoint and DriverProc?

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

3

Tim Roberts wrote:

Michael Ost & Martha Wade wrote:
> How can I build a windows multimedia “installable driver”
> …
> Unfortunately the app crashes inside windows on return. I suspect it has
> to do with calling conventions but poking around in the dark.

Why are you in the dark? The declaration of DriverOpen, including the
calling convention, is in mmsystem.h.

The absence of any sample code, I guess. But between your answers and my
explorations I think the day is dawning for me.

> * if can I use the Visual Studio compiler for this kind of project, any
> clues about what settings to use?

The only thing to double-check is that DriverProc is declared CALLBACK,
which means __stdcall. The DDK defaults to __cdecl.

That was the key. I used the “big stick” approach and changed to stdcall
with a compiler option. Your solution is clearly better.

> Debug output:
> First-chance exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005:
> Access violation reading location 0x00000017.
> First-chance exception at 0x7c812a5b in Boomwhacker.exe: Microsoft C++
> exception: [rethrow] @ 0x00000000.
> Unhandled exception at 0x7c901010 in Boomwhacker.exe: 0xC0000005: Access
> violation reading location 0x00000017.
>
> Call stack at the crash:
> ntdll.dll!7c901010()
> winmm.dll!76b42e8e()
> winmm.dll!76b42e53()
>> Boomwhacker.exe!BoomwhackerApp::OnInit() Line 29 + 0x11 C++
>
>
> Acting as a symbol server, that’s ntdll!RtlEnterCriticalSection+0xb,
> winmm!InternalOpenDriver+0x32, winmm!DrvOpen+0x15. It crashed early in
> RtlEnterCriticalSection, grabbing a lock from the thread block at fs:0.
> It sure looks like a stack smash. Can you show us the declaration of
> and the code in your DllEntryPoint and DriverProc?

stdcall did the trick, and thanks again. I am now realizing that I am in
a “deeper” list than I need to be. Sorry for the distraction! Cheers… mo

PS: tho curiosity leads me to ask what you mean by “acting as a symbol
server”. If you don’t mind sharing, how did you get names for the
windows calls or figure out about the thread block and stack smash? Or
is that the just the Voice of Experience? %)

4

Michael Ost & Martha Wade wrote:

Tim Roberts wrote:
>
> Acting as a symbol server, that’s ntdll!RtlEnterCriticalSection+0xb,
> winmm!InternalOpenDriver+0x32, winmm!DrvOpen+0x15. It crashed early in
> RtlEnterCriticalSection, grabbing a lock from the thread block at
> fs:0. It sure looks like a stack smash. Can you show us the
> declaration of
> and the code in your DllEntryPoint and DriverProc?

stdcall did the trick, and thanks again. I am now realizing that I am
in a “deeper” list than I need to be. Sorry for the distraction!
Cheers… mo

PS: tho curiosity leads me to ask what you mean by “acting as a symbol
server”. If you don’t mind sharing, how did you get names for the
windows calls or figure out about the thread block and stack smash? Or
is that the just the Voice of Experience? %)

Visual Studio isn’t very smart about looking up symbols in the standard
DLLs. Us “macho” driver writers use WinDbg, which knows how to extract
and show you those symbols.

In this particular case, I took the brute force approach. I
disassembled ntdll.dll and winmm.dll (using “link /dump /headers
/disasm”) and found the closest symbol to each address. This worked
only because I knew we had the same versions. It’s also possible (and
probably easier, but I keep forgetting about it) to use WinDbg to do
this same job:
“c:\Program Files\Debugging Tools for Windows\windbg.exe” -z
c:\windows\system32\ntdll.dll
And then give the command “u 7c901010”. That will show you the code and
the closest symbol.

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

5

> which means __stdcall. The DDK defaults to __cdecl.

No, DDK defaults to __stdcall, it is the standard VC++ IDE projects who default
to __cdecl.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com