Vista 64-bit Device Driver

NTDEV
1

Hi,

I have a legacy kernel-mode device driver which I’m attempting to port to Windows 64-bit. It’s a legacy driver, and was originally built with an older NTDDK. Despite this, it ran nicely under Windows Vista (32-bit) all the way down to Windows 2000.

In order to compile a 64-bit driver, we downloaded the latest ‘public’ DDK that we could find. (We no longer have an MSDN subscription to get the Vista DDK, unfortunately) So this is the Windows 2003 DDK available on MSDN’s site.

After eliminating all the new warnings and dependency issues, we got a 64-bit compilation of the driver. The problem is that the driver won’t start. This is confirmed through System Information utility, and Event Log viewer. I can’t figure out why. The Event Log viewer doesn’t provide much detail. It simply says that the driver failed to start.

Any ideas? Any suggestions on where to start looking?

I’m building the driver through SOURCES and SETENV.BAT set to WNET AMD64 – my first question is if using WNET would actually compile a driver that was usable under Vista? I tried passing WXP AMD64 instead, but this wouldn’t compile, since this version of the DDK does not provide AMD64 libs for WXP. (My second question would be: why is that? Do I need the Vista DDK for that?)

I read somewhere that newer versions of Windows were picky about legacy NT API calls. And so “link /dump /imports mydriver.sys” reports that there is nothing of the sort.

Also, I read that if certain libraries were linked into the driver (such as ntdll.lib) that 64-bit Vista would refuse to load the driver because of this. But SOURCES has TARGETTYPE set to DRIVER, and so the only libs that get linked are the standard ntoskrnl.lib, hal.lib, and wmilib.lib. A “link /dump /depedents mydriver.sys” shows that the only dependency is ntoskrnl.exe. I tried removing that dependency, but found out (real quick) that including that lib was definitely a necesscity. (Removing hal.lib and wmilib.lib made no difference)

Next, I compiled the driver as a regular 32-bit binary with SETENV.BAT set to W2K alone. I did this just to see if the 32-bit driver still worked with the new version of the DDK. And so it does, but at this point I’m not sure where to start looking next.

Any ideas?

2

There are too many questions unanswered. What type of driver is this? If a
PnP driver, what stack is it using and is it a filter or a fuction driver?
There is no 64-bit XP. It is just a marketing fanatsy. That version is
really Windows 2003 SP1 stripped of server capabilities with the consumer
stuff added. The WDK was available on the connect site, but has migrated to
MSDN only, AFAIK.

wrote in message news:xxxxx@ntdev…
> Hi,
>
> I have a legacy kernel-mode device driver which I’m attempting to port to
> Windows 64-bit. It’s a legacy driver, and was originally built with an
> older NTDDK. Despite this, it ran nicely under Windows Vista (32-bit) all
> the way down to Windows 2000.
>
> In order to compile a 64-bit driver, we downloaded the latest ‘public’ DDK
> that we could find. (We no longer have an MSDN subscription to get the
> Vista DDK, unfortunately) So this is the Windows 2003 DDK available on
> MSDN’s site.
>
> After eliminating all the new warnings and dependency issues, we got a
> 64-bit compilation of the driver. The problem is that the driver won’t
> start. This is confirmed through System Information utility, and Event
> Log viewer. I can’t figure out why. The Event Log viewer doesn’t provide
> much detail. It simply says that the driver failed to start.
>
> Any ideas? Any suggestions on where to start looking?
>
> I’m building the driver through SOURCES and SETENV.BAT set to WNET
> MD64 – my first question is if using WNET would actually compile a
> driver that was usable under Vista? I tried passing WXP AMD64 instead,
> but this wouldn’t compile, since this version of the DDK does not provide
> AMD64 libs for WXP. (My second question would be: why is that? Do I need
> the Vista DDK for that?)
>
> I read somewhere that newer versions of Windows were picky about legacy NT
> API calls. And so “link /dump /imports mydriver.sys” reports that there is
> nothing of the sort.
>
> Also, I read that if certain libraries were linked into the driver (such
> as ntdll.lib) that 64-bit Vista would refuse to load the driver because of
> this. But SOURCES has TARGETTYPE set to DRIVER, and so the only libs that
> get linked are the standard ntoskrnl.lib, hal.lib, and wmilib.lib. A
> “link /dump /depedents mydriver.sys” shows that the only dependency is
> ntoskrnl.exe. I tried removing that dependency, but found out (real
> quick) that including that lib was definitely a necesscity. (Removing
> hal.lib and wmilib.lib made no difference)
>
> Next, I compiled the driver as a regular 32-bit binary with SETENV.BAT set
> to W2K alone. I did this just to see if the 32-bit driver still worked
> with the new version of the DDK. And so it does, but at this point I’m
> not sure where to start looking next.
>
> Any ideas?
>
>

3

WDK is available as a free download from connect.microsoft.com. WDK 6001 is
the latest. Also only signed drivers load in Vista 64. If you want to load
unsigned drivers (during development) you have a boot option to disable
driver signature enforcement.

-Saravanan J

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, February 04, 2008 10:29 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Vista 64-bit Device Driver

Hi,

I have a legacy kernel-mode device driver which I’m attempting to port to
Windows 64-bit. It’s a legacy driver, and was originally built with an
older NTDDK. Despite this, it ran nicely under Windows Vista (32-bit) all
the way down to Windows 2000.

In order to compile a 64-bit driver, we downloaded the latest ‘public’ DDK
that we could find. (We no longer have an MSDN subscription to get the
Vista DDK, unfortunately) So this is the Windows 2003 DDK available on
MSDN’s site.

After eliminating all the new warnings and dependency issues, we got a
64-bit compilation of the driver. The problem is that the driver won’t
start. This is confirmed through System Information utility, and Event Log
viewer. I can’t figure out why. The Event Log viewer doesn’t provide much
detail. It simply says that the driver failed to start.

Any ideas? Any suggestions on where to start looking?

I’m building the driver through SOURCES and SETENV.BAT set to WNET AMD64 –
my first question is if using WNET would actually compile a driver that was
usable under Vista? I tried passing WXP AMD64 instead, but this wouldn’t
compile, since this version of the DDK does not provide AMD64 libs for WXP.
(My second question would be: why is that? Do I need the Vista DDK for
that?)

I read somewhere that newer versions of Windows were picky about legacy NT
API calls. And so “link /dump /imports mydriver.sys” reports that there is
nothing of the sort.

Also, I read that if certain libraries were linked into the driver (such as
ntdll.lib) that 64-bit Vista would refuse to load the driver because of
this. But SOURCES has TARGETTYPE set to DRIVER, and so the only libs that
get linked are the standard ntoskrnl.lib, hal.lib, and wmilib.lib. A “link
/dump /depedents mydriver.sys” shows that the only dependency is
ntoskrnl.exe. I tried removing that dependency, but found out (real quick)
that including that lib was definitely a necesscity. (Removing hal.lib and
wmilib.lib made no difference)

Next, I compiled the driver as a regular 32-bit binary with SETENV.BAT set
to W2K alone. I did this just to see if the 32-bit driver still worked with
the new version of the DDK. And so it does, but at this point I’m not sure
where to start looking next.

Any ideas?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

On Sun, Feb 03, 2008 at 11:59:15PM -0500, xxxxx@gmail.com wrote:

Hi,

I have a legacy kernel-mode device driver which I’m attempting to port
to Windows 64-bit. It’s a legacy driver, and was originally built with
an older NTDDK. Despite this, it ran nicely under Windows Vista (32-bit)
all the way down to Windows 2000.
…

After eliminating all the new warnings and dependency issues, we got
a 64-bit compilation of the driver. The problem is that the driver
won’t start. This is confirmed through System Information utility, and
Event Log viewer. I can’t figure out why. The Event Log viewer doesn’t
provide much detail. It simply says that the driver failed to start.

Any ideas? Any suggestions on where to start looking?

Vista 64 will not load a 64-bit driver at all unless it has a digital
signature by a code-signing certificate from one of the few remaining
certificate companies. You can create your own certificate for your
own testing, by booting your test machine with the /testsign option,
but to deliver the driver you will need a real code signing certificate.

This read will prove fruitful:
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

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

5

Hi David,

This is a functional driver. It emulates CD/DVD-ROM and hard drives. It calls IoCreateDevice inside DriverEntry and allocates FILE_DEVICE_DISK or FILE_DEVICE_CD_ROM devices (hence legacy, and is not implementing any PnP) The underlying concept of the driver is quite similar to the RAMDISK example on MSDN.

If DriverEntry is called by the OS, do you know if Event Viewer would report its returned NTSTATUS value on failure? I am not seeing any information like that. It just says that the driver failed to load. I think this might be an indication that DriverEntry is not being invoked at all. If I’m wrong, please tell me. At least I see that the OS is attempting to load the driver, but if it does not call DriverEntry, I have to wonder if there is something wrong with the way the driver is compiled.

Thanks for the info on 64-bit XP (the fact that there isn’t any) It reminds me how OLE was marketed COM, DCOM, COM+, ActiveX, .NET, WinFX, er, let’s make that .NET 3

6

Take a course in developing device drivers and the use of windbg. I have
never used event viewer for my drivers unless I was testing its logging
capabilities. Run the debugger and see if DriverEntry is entered.

wrote in message news:xxxxx@ntdev…
> Hi David,
>
> This is a functional driver. It emulates CD/DVD-ROM and hard drives. It
> calls IoCreateDevice inside DriverEntry and allocates FILE_DEVICE_DISK or
> FILE_DEVICE_CD_ROM devices (hence legacy, and is not implementing any PnP)
> The underlying concept of the driver is quite similar to the RAMDISK
> example on MSDN.
>
> If DriverEntry is called by the OS, do you know if Event Viewer would
> report its returned NTSTATUS value on failure? I am not seeing any
> information like that. It just says that the driver failed to load. I
> think this might be an indication that DriverEntry is not being invoked at
> all. If I’m wrong, please tell me. At least I see that the OS is
> attempting to load the driver, but if it does not call DriverEntry, I have
> to wonder if there is something wrong with the way the driver is compiled.
>
> Thanks for the info on 64-bit XP (the fact that there isn’t any) It
> reminds me how OLE was marketed COM, DCOM, COM+, ActiveX, .NET, WinFX, er,
> let’s make that .NET 3
>
>

7

Hi Saravanan, Tim,

I actually thought this was the case for Vista as a whole, but when I saw the unsigned driver run on Vista 32, I just thought Vista 64 would be equally forgiving. Oh well. Any specific reason why it’s not?

Thank you for the links!

8

Hi David,

A debugger is useless when the driver isn’t even loading.

9

On Feb 4, 2008 12:08 PM, wrote:

> Hi David,
>
> This is a functional driver. It emulates CD/DVD-ROM and hard drives. It
> calls IoCreateDevice inside DriverEntry

DriverEntry() is calling IoCreateDevice()?

I thought the basic responsibility of AddDevice() in a function driver is
to create a device object and link it into the stack rooted in PDO.
AddDevice() will call IoCreateDevice ().

> and allocates FILE_DEVICE_DISK or FILE_DEVICE_CD_ROM devices (hence
> legacy, and is not implementing any PnP) The underlying concept of the
> driver is quite similar to the RAMDISK example on MSDN.
>
> If DriverEntry is called by the OS, do you know if Event Viewer would
> report its returned NTSTATUS value on failure? I am not seeing any
> information like that. It just says that the driver failed to load. I think
> this might be an indication that DriverEntry is not being invoked at all. If
> I’m wrong, please tell me. At least I see that the OS is attempting to load
> the driver, but if it does not call DriverEntry, I have to wonder if there
> is something wrong with the way the driver is compiled.
>
> Thanks for the info on 64-bit XP (the fact that there isn’t any) It
> reminds me how OLE was marketed COM, DCOM, COM+, ActiveX, .NET, WinFX, er,
> let’s make that .NET 3
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

10

Hi Yogesh,

That would definitely be the case for a WDM driver written today, making it device centric, but this driver was written many years ago. OK, time to rewrite it.

11

Why dont you just try DbgPrint with DbgView application? In your
DriverEntry() routine, just add DbgPrints and display the NTSTATUS values.
At initial level you dont have to go for WinDbg.

On Feb 4, 2008 12:27 PM, wrote:

> Hi David,
>
> A debugger is useless when the driver isn’t even loading.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

12

Saravanan and Tim were quick to catch that the driver is unsigned. We’re not ‘signing’ the driver for Vista 64, and so this is the reason why the driver is not getting loaded. Thank you!

13

It would be if you said that you had tried it and seen that it was not
loading. Either set a breakpoint on DriverEntry or call DbgBreakPoint() the
first thing in DriverEntry. Vista 64-bit will not permit unsigned drivers
to load unless you are debugging, use F8, or get a certificate and sign the
driver.

wrote in message news:xxxxx@ntdev…
> Hi David,
>
> A debugger is useless when the driver isn’t even loading.
>
>

14

>OLE was marketed COM, DCOM, COM+, ActiveX, .NET, WinFX, er, let’s make

.NET has nothing to do with OLE (though can provide OLE-compatibility)

COM+ is actually renamed Microsoft Transaction Server with code moved from MTS
DLLs to ole32.dll itself.

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

15

> *DriverEntry*() is calling *IoCreateDevice*()?

Normal for non-PnP (i.e. control) device objects.

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

16

xxxxx@gmail.com wrote:

I actually thought this was the case for Vista as a whole, but when I
saw the unsigned driver run on Vista 32, I just thought Vista 64
would be equally forgiving. Oh well. Any specific reason why it’s
not?

Here MS documents what’s possibly, and where:
http://msdn2.microsoft.com/en-us/library/aa906239.aspx

This is my idea about the underlying reasons:

(a) You cannot have a secure operating system if all drivers can
bypass all security and access control mechanisms. Code signing per se
does not make the driver secure, but now you can track the developer.
(And if a certificate is stolen, you can at least revoke it.)

(b) The Vista64 customer base is probably relatively small, consisting
primarily of people who need the additional 64bit power, e.g. for
servers. These people are more likely to buy into a tradeoff of some
inconvenience versus improved stability. You could not have started
enforcing code signing for kernel drivers with on 32bit platforms - who
would buy Vista32 then if there was no re-usable XP driver base?

(c) Microsoft has to provide a secure media playback platform, otherwise
the film industry would not have accepted any high-definition content
playback on Vista. Note that even on Vista32 the “Drivers that stream
protected content.” have to be signed.

(d) Microsoft introduced User-Mode Driver Framework (UMDF) with Vista.
UMDF drivers don’t need to be signed. Of course using user mode you pay
with some performance loss, but in return get much higher system
stability. And convenience - UMDF does a lot of housekeeping for you.

Comments welcome. Bob? Doron? :slight_smile:
-H

17

> (c) Microsoft has to provide a secure media playback platform, otherwise

From what I’ve heard, this is the main reason. Supporting the 3rd party
vendor’s copy protection schemes is another.

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

18

Hi Maxim,

That’s like saying, “Human beings have nothing to do with apes.”

Take a look at COM on Wikipedia, and see how .NET and OLE are related. You’re confusing ‘OLE Automation’ and early ‘OLE 1.0’. (For good reason)

19

Hi Hagen,

Thanks for the info. It’s funny though, don’t you think, since only (b) is specific to 64-bit Vista and (b) is becoming less true, due to a growing number of home consumers with 64-bit Vista (as shows our customer base)

UMDF sounds likes an option. I’m glad I found this place. It’s hard to keep up with all these new technologies. Seems like yesterday I was learning the wonders of NTDDK…

20

Thanks for tips, David… Maybe one day I can take another (more current) course on developing device drivers. Being a specialist in the technology always helps too.

:slight_smile: