Windows 8 test signing fun

So I have a Windows 7 driver test signed, certificate is in the localMachine root, cat files signed etc and it installs fine on WIndows 7.

So I tested on Windows 8 doing an Update Driver Software in Device Manager…

“Driver is not signed”.

Test signing is on, and the machine is booted into F7 ‘disble driver signature enforcement’ each time.

Hmm, odd. The certificate was imported with the certmgr.exe tool in accordance with the MS doc, KMCS_Walkthrough, the cat files are created and signed in accordane with the doc, inf2cat and signtool, so whats the problem?

So I faffed and furkled and fiddled and said another word starting with ‘f’ a few times finally fixed it.

Right click the inf, do an install, reboot and do the same Update Driver Software in Device Manager.

BINGO! It now says it is signed.

So whats the difference doing a right click on an inf-> Install-> Update Driver Software and just an Update Driver Software?

Windows 8 build is is 9200 by the way.

xxxxx@hotmail.com wrote:

So I have a Windows 7 driver test signed, certificate is in the localMachine root, cat files signed etc and it installs fine on WIndows 7.

So I tested on Windows 8 doing an Update Driver Software in Device Manager…

“Driver is not signed”.

Test signing is on, and the machine is booted into F7 ‘disble driver signature enforcement’ each time.

Hmm, odd. The certificate was imported with the certmgr.exe tool in accordance with the MS doc, KMCS_Walkthrough, the cat files are created and signed in accordane with the doc, inf2cat and signtool, so whats the problem?

So I faffed and furkled and fiddled and said another word starting with ‘f’ a few times finally fixed it.

Right click the inf, do an install, reboot and do the same Update Driver Software in Device Manager.

BINGO! It now says it is signed.

So whats the difference doing a right click on an inf-> Install-> Update Driver Software and just an Update Driver Software?

What kind of driver is this, exactly? For a PnP driver, a right-click
install doesn’t do anything at all.


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

Tim Roberts wrote:

What kind of driver is this, exactly?

I have a sneaking suspicion it’s a non-PnP driver, that just so happens to monkey with the CPU clock speed…

It is a filter driver, and no, it doesnt ‘monkey’ with the CPU, it uses the corect and documented way to control CPU speed. Whether one sees supplementing the role of intelppm.sys as monkeying or not is a conceptual/moral debate and not a technical one and one I dont wish to repeat. It is a machine, it does what is asked of it. (In fact the program manager had tried a number of user mode approaches to this and didnt get what was required hence the kernel approach wich has proved to be very effective and stable).

Oh, and while we are at it, intelppm.sys does not pass the HCT test, it has a memory leak.

No takers from Microsoft on this? You have some seriously different behaviour between Windows * and 7, and if you follow the documentation, KMCS_Walkthrough, it doesnt work. It needs either fixing or documenting.

And how about intelppm.sys not passing HCT? Dont you think Intel might need to know this, it is a MS shipped file, it should at least live up to the standards imposed on the rest of us.

xxxxx@hotmail.com wrote:

It is a filter driver, and no, it doesnt ‘monkey’ with the CPU, it uses the corect and documented way to control CPU speed.

OK, hold on a moment. You don’t install a filter driver using “Update
Driver Software.” Are you saying you have a complete PnP driver package
that happens to install a standard driver PLUS your filter?

Whether one sees supplementing the role of intelppm.sys as monkeying or not is a conceptual/moral debate and not a technical one and one I dont wish to repeat. It is a machine, it does what is asked of it. (In fact the program manager had tried a number of user mode approaches to this and didnt get what was required hence the kernel approach wich has proved to be very effective and stable).

Oh, and while we are at it, intelppm.sys does not pass the HCT test, it has a memory leak.

I find that very hard to believe. Every computer (well, virtually every
computer) being sold in a retail store today running Windows 8 has
passed the HCT, and most of then are using intelppm.sys. It’s possible
your filter is triggering some path that hasn’t been executed before, I
guess, but intelppm.sys has been around since the XP days. It has a
very long history.


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

> Are you saying you have a complete PnP driver package

that happens to install a standard driver PLUS your filter?

Yes, my inf calls into CPU.inf for the standard driver install.

I find that very hard to believe.

Dont forget verifier is VERY specific. If a module allocates memory IT must free it. Of course intelppm.sys doesnt ever get an IRP_MJ_REMOVE_DEVICE untill the machine is just about shutdown, so it is not a scenario that has probably ever been tested.

As for my filter, it doesnt touch the Irps going from intelppm to acpi, they are all passed on. In fact during HCT my driver is actually totally inactive.

Here is the dump:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

Arg1: 00000062, A driver has forgotten to free its pool allocations prior to unloading.

IMAGE_NAME: intelppm.sys

d> !verifier 3 intelppm.sys

Verify Level 9bb … enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled

Summary of All Verifier Statistics

RaiseIrqls 0x32
AcquireSpinLocks 0x162831
Synch Executions 0x0
Trims 0xcca1

Pool Allocations Attempted 0x24f443
Pool Allocations Succeeded 0x24f443
Pool Allocations Succeeded SpecialPool 0x24f443
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x36 for 00001AA4 bytes
Peak paged pool allocations 0x41 for 0000D21C bytes
Current nonpaged pool allocations 0x109 for 00014A98 bytes
Peak nonpaged pool allocations 0x1a3 for 0001EF38 bytes

Driver Verification List

Entry State NonPagedPool PagedPool Module

84110ba0 Loaded 000003c8 0000001c intelppm.sys

Current Pool Allocations 00000008 00000001
Current Pool Bytes 000003c8 0000001c
Peak Pool Allocations 0000000c 00000004
Peak Pool Bytes 00000500 00000c1c

PoolAddress SizeInBytes Tag CallersAddress
8cb94fe0 0x00000020 Prcr 8b65ac60
8cb92e80 0x00000180 Prcr 8b65ac35
889f4fe0 0x0000001c Prcr 8b65a8ba
8cb90ff0 0x0000000c Prcr 8b65ac05
a6730fd8 0x00000024 Prcr 8b65b29f
a5ba0fa0 0x00000060 Prcr 8b65b270
8cb3cf38 0x000000c8 Prcr 8b65c1fa
8cb54f58 0x000000a4 Prcr 8b65e9ed
a51e4fd0 0x0000002c Prcr 8b65be6a

Prcr is NOT my tag, and like I said my drivers control DO is totaly inactive anyway, it isnt allocating tagged memory.

So yes, believe it, intelppm.sys really is leaking memory according to HCT.

Pnp drivers don’t get a remove device irp on shutdown. They are sent an s5 power irp, power themselves down and then the system turns off. No driver unloading. That means you are introducing this path .

d

Bent from my phone


From: xxxxx@hotmail.commailto:xxxxx
Sent: ?4/?2/?2013 4:09 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Windows 8 test signing fun

> Are you saying you have a complete PnP driver package
>that happens to install a standard driver PLUS your filter?

Yes, my inf calls into CPU.inf for the standard driver install.

>I find that very hard to believe.

Dont forget verifier is VERY specific. If a module allocates memory IT must free it. Of course intelppm.sys doesnt ever get an IRP_MJ_REMOVE_DEVICE untill the machine is just about shutdown, so it is not a scenario that has probably ever been tested.

As for my filter, it doesnt touch the Irps going from intelppm to acpi, they are all passed on. In fact during HCT my driver is actually totally inactive.

Here is the dump:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

Arg1: 00000062, A driver has forgotten to free its pool allocations prior to unloading.

IMAGE_NAME: intelppm.sys

d> !verifier 3 intelppm.sys

Verify Level 9bb … enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled

Summary of All Verifier Statistics

RaiseIrqls 0x32
AcquireSpinLocks 0x162831
Synch Executions 0x0
Trims 0xcca1

Pool Allocations Attempted 0x24f443
Pool Allocations Succeeded 0x24f443
Pool Allocations Succeeded SpecialPool 0x24f443
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x36 for 00001AA4 bytes
Peak paged pool allocations 0x41 for 0000D21C bytes
Current nonpaged pool allocations 0x109 for 00014A98 bytes
Peak nonpaged pool allocations 0x1a3 for 0001EF38 bytes

Driver Verification List

Entry State NonPagedPool PagedPool Module

84110ba0 Loaded 000003c8 0000001c intelppm.sys

Current Pool Allocations 00000008 00000001
Current Pool Bytes 000003c8 0000001c
Peak Pool Allocations 0000000c 00000004
Peak Pool Bytes 00000500 00000c1c

PoolAddress SizeInBytes Tag CallersAddress
8cb94fe0 0x00000020 Prcr 8b65ac60
8cb92e80 0x00000180 Prcr 8b65ac35
889f4fe0 0x0000001c Prcr 8b65a8ba
8cb90ff0 0x0000000c Prcr 8b65ac05
a6730fd8 0x00000024 Prcr 8b65b29f
a5ba0fa0 0x00000060 Prcr 8b65b270
8cb3cf38 0x000000c8 Prcr 8b65c1fa
8cb54f58 0x000000a4 Prcr 8b65e9ed
a51e4fd0 0x0000002c Prcr 8b65be6a

Prcr is NOT my tag, and like I said my drivers control DO is totaly inactive anyway, it isnt allocating tagged memory.

So yes, believe it, intelppm.sys really is leaking memory according to HCT.


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

Assuming of course it is occuring at Remove device. I am only assuming that because verifier is reporting the error occuring when intelppm.sys unloads:

“A driver has forgotten to free its pool allocations prior to unloading”

How do you suppose a filter driver that does nothing to the FDO Irps except pass them to the PDO could introduce a new path? How could it generate an IRP_MJ_REMOVE device accidentally, it certainly doesnt do anysuch thing explicitely.

Oh, I forgot, I also ran the HCT CHAOS test on the CPU without my driver bing installed, and the same Verifier BSOD occured in intelppm.sys so it is deffinitely NOT something my driver is doing.