64bit driver not loading after single line of code added

I have an export driver which loads happily in checked build but not free build on Server 2008 R2 (amd64) . If the same driver is compiled for 32-bit XP then it loads without issue for both free and checked builds.

The event log shows that the driver was not loaded but does not give any status code reason for why the driver does not load. I have driver verifier enabled and in the debugger I can see that the driver verifier header for this driver (and consequently the parent driver) are not shown because the drivers do not load.

There are no build warnings and I have run prefast checks.

I have found that for the amd64 free build I can get the drivers to load if I comment out a few lines of code in a particular function. Then if I copy a line of existing code (which was not commented out) in the same function and duplicate it within the same function the driver will not load! So it cannot be missing a runtime library because its the same line of code that was copied.

What should I be looking at to diagnose? Is their anything I should check for with dumpbin?

Any suggestions much appreciated.

I would try to load the module with WinDbg (Open .sys file) and check different characteristics of the binary.
run the following command on both instances of binaries and see what is changed:
!lmi driver.sys
!dh driver.sys

*Maybe* your driver is too big so it exceed the non paged memory size for the code but I hardly believe this is the case…
Maybe you send here the line you add which cause the failure…

>

I have an export driver which loads happily in checked build but not free build
on Server 2008 R2 (amd64) . If the same driver is compiled for 32-bit XP then
it loads without issue for both free and checked builds.

The event log shows that the driver was not loaded but does not give any
status code reason for why the driver does not load. I have driver verifier
enabled and in the debugger I can see that the driver verifier header for this
driver (and consequently the parent driver) are not shown because the
drivers do not load.

There are no build warnings and I have run prefast checks.

I have found that for the amd64 free build I can get the drivers to load if I
comment out a few lines of code in a particular function. Then if I copy a line
of existing code (which was not commented out) in the same function and
duplicate it within the same function the driver will not load! So it cannot be
missing a runtime library because its the same line of code that was copied.

What should I be looking at to diagnose? Is their anything I should check for
with dumpbin?

Any suggestions much appreciated.

I encountered a similar problem once. I had allocated an excessive amount of space on the stack (local vars) and a very minor change to the code caused it to no longer work. I’m pretty sure that this was in a scsiport driver and the crash was happening at DIRQL, so the stack requirements there are probably different to what you are seeing, but if you are out of ideas have a look there. I was getting a complete system freeze though, not just a driver failing to load…

Also, have you checked that your driver is being signed correctly after the change? An easy way to check would be to boot with driver signing disabled (does that option still exist?) I’d expect a logged message in that case though.

I hate problems like this. You have my sympathies.

James

Show us the code that is causing the issue . It’s most likely an import resolution issue, run depends.exe on the driver on the test machine and see what it says

d

debt from my phone


From: xxxxx@brandcomms.com
Sent: 10/25/2012 4:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] 64bit driver not loading after single line of code added

I have an export driver which loads happily in checked build but not free build on Server 2008 R2 (amd64) . If the same driver is compiled for 32-bit XP then it loads without issue for both free and checked builds.

The event log shows that the driver was not loaded but does not give any status code reason for why the driver does not load. I have driver verifier enabled and in the debugger I can see that the driver verifier header for this driver (and consequently the parent driver) are not shown because the drivers do not load.

There are no build warnings and I have run prefast checks.

I have found that for the amd64 free build I can get the drivers to load if I comment out a few lines of code in a particular function. Then if I copy a line of existing code (which was not commented out) in the same function and duplicate it within the same function the driver will not load! So it cannot be missing a runtime library because its the same line of code that was copied.

What should I be looking at to diagnose? Is their anything I should check for with dumpbin?

Any suggestions much appreciated.


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

Thanks everyone for your suggestions. I still have the issue but can provide some feedback.

The dependency check shows just two dependencies which are found (NTOSKRNL and KSECDD)

I have used the checked Windows build with NTOSPNP Debug print filter tracing enabled but still no assertions or debug shown.

Then I found Doron’s excellent blog on debugging driver loading through MmLoadSystemImage breakpoints (http://blogs.msdn.com/b/doronh/archive/2006/03/13/550844.aspx). I found that MiDriverLoadSucceeded was called for my export driver, and MiLogFailedDriverLoad was called for the parent miniport driver. IopLoadDriver returned C0000199 (the specified image is already loaded as a dll)?

My current conclusions are that the miniport driver will not load if the export driver image size exceeds 0x40000 bytes. If I uncomment *any* code to reduce the image size >=0x40000 (even a mundane line of debug) the drivers will load. But if I add any line of code to bump the image size up a fraction to say 0x40080 then the miniport driver will not load.

What I did find from displaying the image headers is that the size of the stack reserve is 0x40000 bytes which coincidently is the maximum image size I am able to load!

The parent miniport driver is appas.sys and the export driver is apdtls.sys.

kd> !dh apdtls.sys
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
50913D3F time date stamp Wed Oct 31 15:01:19 2012

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
31280 size of code
EA80 size of initialized data
0 size of uninitialized data
3F2E4 address of entry point
380 base of code
----- new -----
0000000000010000 image base
80 section alignment
80 file alignment
1 subsystem (Native)
6.01 operating system version
6.01 image version
6.01 subsystem version
40080 size of image
380 size of headers
44A90 checksum
0000000000040000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit


When Drivers successfully load:

kd> !lmi apdtls.sys
Loaded Module Info: [apdtls.sys]
Module: APDTLS
Base Address: fffff88004dbf000
Image Name: APDTLS.SYS
Machine Type: 34404 (X64)
Time Stamp: 50913897 Wed Oct 31 14:41:27 2012
Size: 40000
CheckSum: 4b753
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 63, 38a5c, 38a5c RSDS - GUID: {0559C1B2-A157-4237-A026-784F3BEC4E65}
kd> lm t n
start end module name
fffff88004c12000 fffff88004dbe900 APPAS APPAS.sys Wed Oct 31 09:33:59 2012 (5090F087)
fffff88004dbf000 fffff88004dff000 APDTLS APDTLS.SYS Wed Oct 31 14:41:27 2012 (50913897)


When Drivers fail to load:

kd> !lmi apdtls.sys
Loaded Module Info: [apdtls.sys]
Module: APDTLS
Base Address: fffff88004c00000
Image Name: APDTLS.SYS
Machine Type: 34404 (X64)
Time Stamp: 50913a5d Wed Oct 31 14:49:01 2012
Size: 40080
CheckSum: 4aa24
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 63, 38adc, 38adc RSDS - GUID: {94A32B0D-F4E9-4FB1-B3B0-AFC692D08C0D}

kd> lm t n
start end module name
fffff88004c00000 fffff88004c40080 APDTLS APDTLS.SYS Wed Oct 31 14:49:01 2012 (50913A5D)

Unloaded modules:
fffff88006632000 fffff880067df000 APPAS.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 001AD000
fffff880027a4000 fffff880027b8000 crashdmp.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 00014000
fffff880027b8000 fffff880027c6000 dump_pciidex.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 0000E000
fffff880027c6000 fffff880027d1000 dump_msahci.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 0000B000
fffff88004c51000 fffff88004dfe000 APPAS.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 001AD000

Alan

Is your export driver (apdtls.sys ? ) listed under the services key as a driver? Or does it just live under system32\drivers with no registry entries?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@brandcomms.com
Sent: Wednesday, October 31, 2012 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 64bit driver not loading after single line of code added

Thanks everyone for your suggestions. I still have the issue but can provide some feedback.

The dependency check shows just two dependencies which are found (NTOSKRNL and KSECDD)

I have used the checked Windows build with NTOSPNP Debug print filter tracing enabled but still no assertions or debug shown.

Then I found Doron’s excellent blog on debugging driver loading through MmLoadSystemImage breakpoints (http://blogs.msdn.com/b/doronh/archive/2006/03/13/550844.aspx). I found that MiDriverLoadSucceeded was called for my export driver, and MiLogFailedDriverLoad was called for the parent miniport driver. IopLoadDriver returned C0000199 (the specified image is already loaded as a dll)?

My current conclusions are that the miniport driver will not load if the export driver image size exceeds 0x40000 bytes. If I uncomment *any* code to reduce the image size >=0x40000 (even a mundane line of debug) the drivers will load. But if I add any line of code to bump the image size up a fraction to say 0x40080 then the miniport driver will not load.

What I did find from displaying the image headers is that the size of the stack reserve is 0x40000 bytes which coincidently is the maximum image size I am able to load!

The parent miniport driver is appas.sys and the export driver is apdtls.sys.

kd> !dh apdtls.sys
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
50913D3F time date stamp Wed Oct 31 15:01:19 2012

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
31280 size of code
EA80 size of initialized data
0 size of uninitialized data
3F2E4 address of entry point
380 base of code
----- new -----
0000000000010000 image base
80 section alignment
80 file alignment
1 subsystem (Native)
6.01 operating system version
6.01 image version
6.01 subsystem version
40080 size of image
380 size of headers
44A90 checksum
0000000000040000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit


When Drivers successfully load:

kd> !lmi apdtls.sys
Loaded Module Info: [apdtls.sys]
Module: APDTLS
Base Address: fffff88004dbf000
Image Name: APDTLS.SYS
Machine Type: 34404 (X64)
Time Stamp: 50913897 Wed Oct 31 14:41:27 2012
Size: 40000
CheckSum: 4b753
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 63, 38a5c, 38a5c RSDS - GUID: {0559C1B2-A157-4237-A026-784F3BEC4E65}
kd> lm t n
start end module name
fffff88004c12000 fffff88004dbe900 APPAS APPAS.sys Wed Oct 31 09:33:59 2012 (5090F087)
fffff88004dbf000 fffff88004dff000 APDTLS APDTLS.SYS Wed Oct 31 14:41:27 2012 (50913897)


When Drivers fail to load:

kd> !lmi apdtls.sys
Loaded Module Info: [apdtls.sys]
Module: APDTLS
Base Address: fffff88004c00000
Image Name: APDTLS.SYS
Machine Type: 34404 (X64)
Time Stamp: 50913a5d Wed Oct 31 14:49:01 2012
Size: 40080
CheckSum: 4aa24
Characteristics: 22
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 63, 38adc, 38adc RSDS - GUID: {94A32B0D-F4E9-4FB1-B3B0-AFC692D08C0D}

kd> lm t n
start end module name
fffff88004c00000 fffff88004c40080 APDTLS APDTLS.SYS Wed Oct 31 14:49:01 2012 (50913A5D)

Unloaded modules:
fffff88006632000 fffff880067df000 APPAS.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 001AD000
fffff880027a4000 fffff880027b8000 crashdmp.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 00014000
fffff880027b8000 fffff880027c6000 dump_pciidex.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 0000E000
fffff880027c6000 fffff880027d1000 dump_msahci.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 0000B000
fffff88004c51000 fffff88004dfe000 APPAS.sys
Timestamp: unavailable (00000000)
Checksum: 00000000
ImageSize: 001AD000

Alan


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

What’s in your ‘sources’ file?

This looks like a known issue in win7. Try linking your driver with the default section alignment (0x1000).

Thanks,
Pavel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@brandcomms.com
Sent: Wednesday, October 31, 2012 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 64bit driver not loading after single line of code added

Thanks everyone for your suggestions. I still have the issue but can provide some feedback.

The dependency check shows just two dependencies which are found (NTOSKRNL and KSECDD)

I have used the checked Windows build with NTOSPNP Debug print filter tracing enabled but still no assertions or debug shown.

Then I found Doron’s excellent blog on debugging driver loading through MmLoadSystemImage breakpoints (http://blogs.msdn.com/b/doronh/archive/2006/03/13/550844.aspx). I found that MiDriverLoadSucceeded was called for my export driver, and MiLogFailedDriverLoad was called for the parent miniport driver. IopLoadDriver returned C0000199 (the specified image is already loaded as a dll)?

My current conclusions are that the miniport driver will not load if the export driver image size exceeds 0x40000 bytes. If I uncomment *any* code to reduce the image size >=0x40000 (even a mundane line of debug) the drivers will load. But if I add any line of code to bump the image size up a fraction to say 0x40080 then the miniport driver will not load.

What I did find from displaying the image headers is that the size of the stack reserve is 0x40000 bytes which coincidently is the maximum image size I am able to load!

The parent miniport driver is appas.sys and the export driver is apdtls.sys.

kd> !dh apdtls.sys
80 section alignment
80 file alignment

Doron - yes apdtls is the export driver. It does not have any registry entries just placed in system32\drivers.
Pavel - the section alignment sounds interesting. Do you have any reference links providing more information (KB article)?

I tried the LINKER_FLAGS macro ALIGN switch but it made no difference. Then I found I could override the alignment by modifying the DRIVER_ALIGNMENT setting in the DDK amd64mk.inc but this was not ideal. Finally I noticed my sources file contained the line DRIVER_ALIGNMENT=0x200. When I removed this line the default makefile alignment values were used.
I now have:
1000 section alignment
200 file alignment
instead of:
80 section alignment
80 file alignment
and the drivers now load!

thanks everyone
Alan.

>Finally I noticed my sources file contained the line DRIVER_ALIGNMENT=0x200.

That’s why I was asking for your ‘SOURCES’