Assert in pci.sys

I have a PCIe x1 device that gets powered down in S3. When the system
resumes from S3, the memory space enable bit is not set in the config space,
and the BARs are no longer configured correctly. I replaced pci.sys with a
checked version, and turned on verbose logging. Pci.sys is asserting on
resume from S3. How can I determine the cause of this assert?

*** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset & 0x3)
== 0)
*** Source File: d:\xpclient\base\busdrv\pci\utils.c, line 3224

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)? b
b
Execute '.cxr A0DB58CC' to dump context
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804e2a46 cc int 3
kd> kb
ChildEBP RetAddr Args to Child
a0db58ac 80542a04 80542b14 a0db5c00 00000001 nt!DbgBreakPoint
a0db5b9c 80542b2c ba7937b4 ba793790 00000c98 nt!RtlAssert2+0x104
a0db5bb8 ba793931 ba7937b4 ba793790 00000c98 nt!RtlAssert+0x18
a0db5be0 ba790a40 85bfab10 000000ff 00000001 pci!PciReadDeviceCapability+0x142
a0db5c08 ba790d01 85bfab10 00000000 00000000 pci!PciPmeAdjustPmeEnable+0x2e
a0db5c1c ba7911ff 85bfab10 00000000 86060ed8 pci!PciPdoAdjustPmeEnable+0x2c
a0db5c38 805054d9 85bfaa58 86060ed8 ba77a9e0
pci!PciPdoWaitWakeCancelRoutine+0x9a
a0db5c50 ba7640da 86060ed8 ba77aff0 85bab308 nt!IoCancelIrp+0x65
a0db5c74 ba7646ea a0db5cf4 ba76449a 85bab308
wdf01000!FxPkgPnp::PowerPolicyCancelWaitWake+0x93
a0db5c7c ba76449a 85bab308 ba77a9e0 85bab308
wdf01000!FxPkgPnp::PowerPolSystemWakeDeviceWakeEna bled+0xd
a0db5cf4 ba764ff3 00000514 85bab480 85bab308
wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
a0db5d1c ba7657bf a0db5d4c 806ff830 85bab474
wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x 21e
a0db5d30 ba7664ee 85bab308 a0db5d4c 85b64b00
wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0 x26
a0db5d60 ba7665af a0db5d7c 8056d03c 85bc58f0
wdf01000!FxEventQueue::EventQueueWorker+0x4a
a0db5d68 8056d03c 85bc58f0 85bab474 8056955c
wdf01000!FxThreadedEventQueue::_WorkItemCallback+0 xd
a0db5d7c 804e23b5 85b64b00 00000000 849746b8 nt!IopProcessWorkItem+0x13
a0db5dac 80574128 85b64b00 00000000 00000000 nt!ExpWorkerThread+0xef
a0db5ddc 804ec791 804e22f1 80000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Thanks!

"Michael" <> wrote in message
news:0A928337-ECE0-45B1-9334-...
> I have a PCIe x1 device that gets powered down in S3. When the system
> resumes from S3, the memory space enable bit is not set in the config
> space,
> and the BARs are no longer configured correctly. I replaced pci.sys with
> a
> checked version, and turned on verbose logging. Pci.sys is asserting on
> resume from S3. How can I determine the cause of this assert?
>
> *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset & 0x3)
> ==0)

As you can see - some offset is either < PCI_COMMON_HDR_LENGTH
(defined in wdm.h) or not aligned on 4 bytes. And this happens in
PciReadDeviceCapability,
so it might be the PM capability.

--PA

Considering the assert is in pci.sys and not in my driver, how do I determine
what the bad offset is, and how to correct it?

"Pavel A." wrote:

> "Michael" <> wrote in message
> news:0A928337-ECE0-45B1-9334-...
> > I have a PCIe x1 device that gets powered down in S3. When the system
> > resumes from S3, the memory space enable bit is not set in the config
> > space,
> > and the BARs are no longer configured correctly. I replaced pci.sys with
> > a
> > checked version, and turned on verbose logging. Pci.sys is asserting on
> > resume from S3. How can I determine the cause of this assert?
> >
> > *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset & 0x3)
> > ==0)
>
> As you can see - some offset is either < PCI_COMMON_HDR_LENGTH
> (defined in wdm.h) or not aligned on 4 bytes. And this happens in
> PciReadDeviceCapability,
> so it might be the PM capability.
>
> --PA
>
>
>
>

"Michael" <> wrote in message
news:AE807913-5750-4A5C-9C97-...
> Considering the assert is in pci.sys and not in my driver, how do I
> determine
> what the bad offset is, and how to correct it?

My guess is this is offset of some PCI capability in the config space
of your card. How to find where exactly?
Try to disassemble near the place where pci.sys calls ASSERT,
maybe the bad value is left in local variables on stack.

--PA




> "Pavel A." wrote:
>
>> "Michael" <> wrote in message
>> news:0A928337-ECE0-45B1-9334-...
>> > I have a PCIe x1 device that gets powered down in S3. When the system
>> > resumes from S3, the memory space enable bit is not set in the config
>> > space,
>> > and the BARs are no longer configured correctly. I replaced pci.sys
>> > with
>> > a
>> > checked version, and turned on verbose logging. Pci.sys is asserting
>> > on
>> > resume from S3. How can I determine the cause of this assert?
>> >
>> > *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset &
>> > 0x3)
>> > ==0)
>>
>> As you can see - some offset is either < PCI_COMMON_HDR_LENGTH
>> (defined in wdm.h) or not aligned on 4 bytes. And this happens in
>> PciReadDeviceCapability,
>> so it might be the PM capability.
>>
>> --PA
>>
>>
>>
>>

Make sure you don't touch your BAR before D0 power IRP returns from PCI.SYS

"Michael" <> wrote in message
news:0A928337-ECE0-45B1-9334-...
>I have a PCIe x1 device that gets powered down in S3. When the system
> resumes from S3, the memory space enable bit is not set in the config
> space,
> and the BARs are no longer configured correctly. I replaced pci.sys with
> a
> checked version, and turned on verbose logging. Pci.sys is asserting on
> resume from S3. How can I determine the cause of this assert?
>
> *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset & 0x3)
> == 0)
> *** Source File: d:\xpclient\base\busdrv\pci\utils.c, line 3224
>
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread
> (boipt)? b
> b
> Execute '.cxr A0DB58CC' to dump context
> Break instruction exception - code 80000003 (first chance)
> nt!DbgBreakPoint:
> 804e2a46 cc int 3
> kd> kb
> ChildEBP RetAddr Args to Child
> a0db58ac 80542a04 80542b14 a0db5c00 00000001 nt!DbgBreakPoint
> a0db5b9c 80542b2c ba7937b4 ba793790 00000c98 nt!RtlAssert2+0x104
> a0db5bb8 ba793931 ba7937b4 ba793790 00000c98 nt!RtlAssert+0x18
> a0db5be0 ba790a40 85bfab10 000000ff 00000001
> pci!PciReadDeviceCapability+0x142
> a0db5c08 ba790d01 85bfab10 00000000 00000000
> pci!PciPmeAdjustPmeEnable+0x2e
> a0db5c1c ba7911ff 85bfab10 00000000 86060ed8
> pci!PciPdoAdjustPmeEnable+0x2c
> a0db5c38 805054d9 85bfaa58 86060ed8 ba77a9e0
> pci!PciPdoWaitWakeCancelRoutine+0x9a
> a0db5c50 ba7640da 86060ed8 ba77aff0 85bab308 nt!IoCancelIrp+0x65
> a0db5c74 ba7646ea a0db5cf4 ba76449a 85bab308
> wdf01000!FxPkgPnp::PowerPolicyCancelWaitWake+0x93
> a0db5c7c ba76449a 85bab308 ba77a9e0 85bab308
> wdf01000!FxPkgPnp::PowerPolSystemWakeDeviceWakeEna bled+0xd
> a0db5cf4 ba764ff3 00000514 85bab480 85bab308
> wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
> a0db5d1c ba7657bf a0db5d4c 806ff830 85bab474
> wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x 21e
> a0db5d30 ba7664ee 85bab308 a0db5d4c 85b64b00
> wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0 x26
> a0db5d60 ba7665af a0db5d7c 8056d03c 85bc58f0
> wdf01000!FxEventQueue::EventQueueWorker+0x4a
> a0db5d68 8056d03c 85bc58f0 85bab474 8056955c
> wdf01000!FxThreadedEventQueue::_WorkItemCallback+0 xd
> a0db5d7c 804e23b5 85b64b00 00000000 849746b8 nt!IopProcessWorkItem+0x13
> a0db5dac 80574128 85b64b00 00000000 00000000 nt!ExpWorkerThread+0xef
> a0db5ddc 804ec791 804e22f1 80000001 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> Thanks!