How to troubleshoot "Code 12"

NTDEV
1

Hi all,

I’m getting a “code 12” (CM_PROB_NORMAL_CONFLICT) when I install my
device driver on win7 32bit which indicates a resource conflict.

How can I use device manager to troubleshoot this? The website states:

To troubleshoot a device conflict

  1. Open Device Manager.
  2. Double-click the icon that represents the device in the Device
    Manager window.
  3. On the device property sheet that appears, click Troubleshoot to
    start the hardware troubleshooter for the device.

However there is no troubleshoot field that I can find on neither the device properties
sheet nor any of device manager’s menus.

When I boot the machine (this is a vm), my device appears in the “Other” class as “Other PCI bridge”
and I find my PIO and MMIO regions as expected. I only get the conflict when I
install my driver and reset the class to “System”. (From what I’ve read, the “Other”
class is reserved)

How do I debug this?

Thanks,
-PWM

2

I would start by looking at \Windows\setupapi.log and see what it says.

The name of that file may have changed again, unfortunately.

mm

3

On Sun, 2009-11-22 at 13:07 -0500, xxxxx@evitechnology.com wrote:

I would start by looking at \Windows\setupapi.log and see what it says.

The name of that file may have changed again, unfortunately.

Well… I turned on verbosity, so it says many things. Among other
things I delete the existing log and copy the one created after the
devcon update so it only has log points for the update. This turns out
to be 45+Kb, in 600 lines.

The ‘driver’ itself is (literally) nothing more than a DriverEntry that
calls an empty (no executable code) DeviceAdd function. A mere
skeleton.

Couple of interesting points in the log:

sig: {_VERIFY_FILE_SIGNATURE} 09:40:29.687
sig: Key = vbus.inf
sig: FilePath = z:\tmp\vbus.inf
sig: Catalog = z:\tmp\vbus.cat
! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

But I also get this here:

sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem1.CAT’.
! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\SETDAE0.tmp.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

So its not clear to me that this is a true error. Note I am using a test cert, and signing the
inf with that cert. I also change the version section date every day, which seems to be required
if I change a source and/or .inx file.

I also get:

dvi: {Restarting Devices} 09:40:46.140
dvi: Restart: PCI\VEN_11DA&DEV_2000&SUBSYS_11001AF4&REV_02\3&13C0B0C5&0&18
dvi: Restart complete.
! dvi: Device required reboot: Device has problem: 0x0c: CM_PROB_NORMAL_CONFLICT.

Which appears to be the issue at hand.

Note also that I am expecting a MSI, and I enable that in the .inf with:

[Vbus_Device.NT.AddReg]
; Use same security checks on relative opens
;HKR,DeviceCharacteristics,0x10001,0x0100
; Allow generic-all access to Built-in administrators and Local system
;HKR,Security,“D:P(A;;GA;;;BA)(A;;GA;;;SY)”
; MSI enablement.
HKR,Interrupt Management,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,MSISupported,0x00010001,1

Which, IIUC, is correct according to the documentation. But even if I comment the above (err, MSI parts) out,
I still fail with the same error in device manager.

Thanks,
-PWM

4

Code 12 tells you the resources your device needs aren’t available. It
might be MMIO, I/O or interrupts in your case. Type !arbiter in the
debugger for a complete list of all the resources claimed in all the
arbiters. Type “!devnode 6” for a list of all the
resources that your device needs. Work your way up the device tree looking
for devices with arbiters to see which one can’t be satisfied.

–
Jake Oshins
Hyper-V I/O Architect (former PnP guy)
Windows Kernel Group

This post implies no warranties and confers no rights.

--------------------------------------------------------------

“Peter W. Morreale” wrote in message
news:xxxxx@ntdev…
>
> Hi all,
>
> I’m getting a “code 12” (CM_PROB_NORMAL_CONFLICT) when I install my
> device driver on win7 32bit which indicates a resource conflict.
>
> How can I use device manager to troubleshoot this? The website states:
>
> To troubleshoot a device conflict
> 1. Open Device Manager.
> 2. Double-click the icon that represents the device in the Device
> Manager window.
> 3. On the device property sheet that appears, click Troubleshoot to
> start the hardware troubleshooter for the device.
>
> However there is no troubleshoot field that I can find on neither the
> device properties
> sheet nor any of device manager’s menus.
>
> When I boot the machine (this is a vm), my device appears in the “Other”
> class as “Other PCI bridge”
> and I find my PIO and MMIO regions as expected. I only get the conflict
> when I
> install my driver and reset the class to “System”. (From what I’ve read,
> the “Other”
> class is reserved)
>
> How do I debug this?
>
> Thanks,
> -PWM
>
>

5

After commenting out the msi parts, are you sure that your newly editted inf is being used? Look at !arbiter in the help, that may help you. Also, !devnode with a particular flag dumps resources (see the help)

d

-----Original Message-----
From: Peter W. Morreale
Sent: Sunday, November 22, 2009 10:29 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] How to troubleshoot “Code 12”

On Sun, 2009-11-22 at 13:07 -0500, xxxxx@evitechnology.com wrote:
> I would start by looking at \Windows\setupapi.log and see what it says.
>
> The name of that file may have changed again, unfortunately.
>
>

Well… I turned on verbosity, so it says many things. Among other
things I delete the existing log and copy the one created after the
devcon update so it only has log points for the update. This turns out
to be 45+Kb, in 600 lines.

The ‘driver’ itself is (literally) nothing more than a DriverEntry that
calls an empty (no executable code) DeviceAdd function. A mere
skeleton.

Couple of interesting points in the log:

sig: {_VERIFY_FILE_SIGNATURE} 09:40:29.687
sig: Key = vbus.inf
sig: FilePath = z:\tmp\vbus.inf
sig: Catalog = z:\tmp\vbus.cat
! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

But I also get this here:

sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem1.CAT’.
! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\SETDAE0.tmp.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

So its not clear to me that this is a true error. Note I am using a test cert, and signing the
inf with that cert. I also change the version section date every day, which seems to be required
if I change a source and/or .inx file.

I also get:

dvi: {Restarting Devices} 09:40:46.140
dvi: Restart: PCI\VEN_11DA&DEV_2000&SUBSYS_11001AF4&REV_02\3&13C0B0C5&0&18
dvi: Restart complete.
! dvi: Device required reboot: Device has problem: 0x0c: CM_PROB_NORMAL_CONFLICT.

Which appears to be the issue at hand.

Note also that I am expecting a MSI, and I enable that in the .inf with:

[Vbus_Device.NT.AddReg]
; Use same security checks on relative opens
;HKR,DeviceCharacteristics,0x10001,0x0100
; Allow generic-all access to Built-in administrators and Local system
;HKR,Security,“D:P(A;;GA;;;BA)(A;;GA;;;SY)”
; MSI enablement.
HKR,Interrupt Management,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,0x00000010
HKR,Interrupt Management\MessageSignaledInterruptProperties,MSISupported,0x00010001,1

Which, IIUC, is correct according to the documentation. But even if I comment the above (err, MSI parts) out,
I still fail with the same error in device manager.

Thanks,
-PWM

—
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

6

On Sun, 2009-11-22 at 12:51 -0800, Jake Oshins wrote:

Code 12 tells you the resources your device needs aren’t available. It
might be MMIO, I/O or interrupts in your case. Type !arbiter in the
debugger for a complete list of all the resources claimed in all the
arbiters. Type “!devnode 6” for a list of all the
> resources that your device needs. Work your way up the device tree looking
> for devices with arbiters to see which one can’t be satisfied.
>

I guess this is the thing that has me so baffled.

With a clean copy (no driver installed) of the VM, device manager
reports the “Other PCI bridge” device in the “Other” class with the
PIO and MMIO BARs.

Only after I install my driver (which changes the class from “Other” to
“System”) do I get the code 12 for my device properties.

Changing the class affects the resources?

I would have thought all I was doing was changing the association of
those resources with a specific driver.

Thx
-PWM

7

What did ‘!arbiter’ report?

mm

8

On Sun, 2009-11-22 at 18:17 -0500, xxxxx@evitechnology.com wrote:

What did ‘!arbiter’ report?

mm

I don’t yet know. I haven’t setup the debugger yet. I was hoping the
documentation was correct and device manager would should the conflicts.
Apparently it does not for Win7.

Best,
-PWM

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

9

This is the place to start - setting up the debugger, that is.

It may be possible to figure out what the problem is with Device Manager; I have no idea, but on this list, windbg is going to be the most well supported tool. Granted, it is a truly beastly tool to learn, but it is what it is, and actually, once you get to know windbg, it’s really a pretty good tool, I think.

It wasn’t all that long ago (a little more than four years) that I had to learn windbg, and I feel your pain; in my case, I was coming from SoftICE, which made the transition a whole lot easier than linux -> windows kernel.

But getting to that point takes a while.

Also, if it makes you feel any better, setup/installation is hands down, no second place the worst feature of windows, by far. Truly awful, truly maddening. Always has been. That’s obviously just my opinion, but I think it safe to say that I’m not alone in feeling that way.

So, I guess what I’m saying is that it will get better.

Good luck,

mm

10

So many weird not-quite-PCI-compliant parts of the various chipsets have
been labeled “Bridge Other” that the only thing we’ve been able to do in the
past is ignore all problems with them, load no driver and leave them in
whatever state the BIOS configured them. Loading your driver starts the
process of treating “Bridge Other” like a valid device.

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Peter W. Morreale” wrote in message
news:xxxxx@ntdev…
> On Sun, 2009-11-22 at 12:51 -0800, Jake Oshins wrote:
>> Code 12 tells you the resources your device needs aren’t available. It
>> might be MMIO, I/O or interrupts in your case. Type !arbiter in the
>> debugger for a complete list of all the resources claimed in all the
>> arbiters. Type “!devnode 6” for a list of all the
>> resources that your device needs. Work your way up the device tree
>> looking
>> for devices with arbiters to see which one can’t be satisfied.
>>
>
> I guess this is the thing that has me so baffled.
>
> With a clean copy (no driver installed) of the VM, device manager
> reports the “Other PCI bridge” device in the “Other” class with the
> PIO and MMIO BARs.
>
> Only after I install my driver (which changes the class from “Other” to
> “System”) do I get the code 12 for my device properties.
>
> Changing the class affects the resources?
>
> I would have thought all I was doing was changing the association of
> those resources with a specific driver.
>
> Thx
> -PWM
>
>

11

On Sun, 2009-11-22 at 17:12 -0800, Jake Oshins wrote:

So many weird not-quite-PCI-compliant parts of the various chipsets have
been labeled “Bridge Other” that the only thing we’ve been able to do in the
past is ignore all problems with them, load no driver and leave them in
whatever state the BIOS configured them. Loading your driver starts the
process of treating “Bridge Other” like a valid device.

Understood.

And I’m beginning to suspect that we are missing something in our PCI
config that Windows cannot handle. In this respect, Linux appears to be
more accepting since we work fine with a broad spectrum of Linux distros
as guests.

The key is to figure out what we are sending or omitting.

Thx,
-PWM

12

On Sun, 2009-11-22 at 20:13 -0500, xxxxx@evitechnology.com wrote:

This is the place to start - setting up the debugger, that is.

It may be possible to figure out what the problem is with Device Manager; I have no idea, but on this list, windbg is going to be the most well supported tool. Granted, it is a truly beastly tool to learn, but it is what it is, and actually, once you get to know windbg, it’s really a pretty good tool, I think.

It wasn’t all that long ago (a little more than four years) that I had to learn windbg, and I feel your pain; in my case, I was coming from SoftICE, which made the transition a whole lot easier than linux -> windows kernel.

Heh, I haven’t used a kernel debugger in years (outside of ‘printk’).

But getting to that point takes a while.

Also, if it makes you feel any better, setup/installation is hands down, no second place the worst feature of windows, by far. Truly awful, truly maddening. Always has been. That’s obviously just my opinion, but I think it safe to say that I’m not alone in feeling that way.

I have found it to be interesting, to say the least.

So, I guess what I’m saying is that it will get better.

I do hope so.

Thx,
-PWM

13

>(outside of ‘printk’).

Well over 90% of the time, that’s more or less how I use windbg.

Along those lines more or less, one thing that might help you is the trace information found in the CHK build. If you’re not using it, you might want to try setting up a partial CHK build - CHK kernel & hal. It might not help, but I’ve found that often there’s trace information and occasionally a useful assert or two that really helps debug either strange problems and/or problems that I haven’t a clue where to begin.

As an added bonus, it requires essentially zero windbg knowledge to use, once your kd session is running that is.

Unfortunately, like many things in Windows, the procedure involved in setting this up is, well, incredibly irritating, but I would still consider doing this, all things considered:

If you’re interested, to get started, you’ll need to download both of the following from MSDN:

CHK build of the version of Windows you are using (7, as I recall)
Windows Automated Installation Kit (WAIK)

If you’re interested, I’ll be happy to fill in the rest of the details.

Good luck,

mm

14

Why can’t you use the checked version of the kernel and hal that comes with
the WIN7 WDK?

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@evitechnology.com
Sent: Sunday, November 22, 2009 9:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to troubleshoot “Code 12”

(outside of ‘printk’).

Well over 90% of the time, that’s more or less how I use windbg.

Along those lines more or less, one thing that might help you is the trace
information found in the CHK build. If you’re not using it, you might want
to try setting up a partial CHK build - CHK kernel & hal. It might not
help, but I’ve found that often there’s trace information and occasionally a
useful assert or two that really helps debug either strange problems and/or
problems that I haven’t a clue where to begin.

As an added bonus, it requires essentially zero windbg knowledge to use,
once your kd session is running that is.

Unfortunately, like many things in Windows, the procedure involved in
setting this up is, well, incredibly irritating, but I would still consider
doing this, all things considered:

If you’re interested, to get started, you’ll need to download both of the
following from MSDN:

CHK build of the version of Windows you are using (7, as I recall) Windows
Automated Installation Kit (WAIK)

If you’re interested, I’ll be happy to fill in the rest of the details.

Good luck,

mm

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

15

You might be able to; I’ve never tried in this particular case. I stopped trying those a long time ago, because I had problems with them.

mm

16

On Sun, 2009-11-22 at 17:12 -0800, Jake Oshins wrote:

So many weird not-quite-PCI-compliant parts of the various chipsets have
been labeled “Bridge Other” that the only thing we’ve been able to do in the
past is ignore all problems with them, load no driver and leave them in
whatever state the BIOS configured them. Loading your driver starts the
process of treating “Bridge Other” like a valid device.

pciview tells us that the busmaster bit (bit 2 of the Command register)
is not set, which is required for MSI.

Our understanding is that the host OS (in this case, Win7) is supposed
to reset this bit during initialization. (it was set at enumeration)

Any PCI experts out there? Is there some capability bit we’re missing?

THanks,
-PWM

17

Peter W. Morreale wrote:

On Sun, 2009-11-22 at 17:12 -0800, Jake Oshins wrote:
> So many weird not-quite-PCI-compliant parts of the various chipsets have
> been labeled “Bridge Other” that the only thing we’ve been able to do in the
> past is ignore all problems with them, load no driver and leave them in
> whatever state the BIOS configured them. Loading your driver starts the
> process of treating “Bridge Other” like a valid device.
>

pciview tells us that the busmaster bit (bit 2 of the Command register)
is not set, which is required for MSI.

Thought I might chime in here. I’m the guy the designed the device that
Peter is trying to interface with. In a nutshell, the device presents
itself as a bridge-other, with an mmio bar at 0, pio bar at 1, and a
single capability at offset 0x40: a single vector MSI.

We can observe that the system seems to map the BARs to valid addresses,
and sets the IO and MEM bits in the command register. However, the BM
bit is left clear, and the MSI is (perhaps coincidentally) never
configured. We have been assuming that the two datapoints are related
(MSI is not configured b/c BM is not enabled), but this is admittedly
merely an educated guess.

Our understanding is that the host OS (in this case, Win7) is supposed
to reset this bit during initialization. (it was set at enumeration)

I think Peter meant to say we expect it to be set during init, and its
initially clear at enumeration. On the linux side, we call
pci_set_master() and pci_enable_msi() in what is effectively the
“DriverAdd()” to perform this function. It is not entirely clear to us
what the equivalent (if any) is on the windows side, or whether windows
is supposed to automagically handle that based on things like the
MSIEnable in the INF.

There is potentially another problem that Peter is seeing w.r.t. the
system reporting conflicting resources when he tries to use other Class
types. We still have yet to get to the bottom of that, but perhaps the
MSI (or lackthereof) is the cause, the effect, or completely unrelated
to this other issue. TBD.

That said, anyone familiar with MSI enough to know what might be
happening here w.r.t. Windows? I can provide the config-space hex dump,
in case it helps.

Kind Regards,
-Greg