Hard crash after EvtDeviceAdd

Hello,

I am busy modifying an existing PCIe KMDF WDF driver I developed years ago for Windows XP/2K/7, to match modified hardware. I’m testing using WinDbg and serial debugging. So far so good.

The driver loads. When I disable and then enable my device in the Device Manager the system hard crashes, mouse freezes and there is no output on the debugger. I cannot seem to break into the target anymore.

The last thing I see in the debugger is the EvtDeviceAdd successfully returning, after that there is no output (EvtPrepareHardware is not called).

I have disabled all code except these functions:
DriverEntry
DriverUnload
EvtDeviceAdd
EvtPrepareHardware (only maps BARs)
EvtReleaseHardware (unmaps BARs)

How can I pick-up debugging this issue?

Thanks,

Leon,

Well, for one thing, you could examine the crash dump to find out why the system crashed.

!analyze -v

and then READ THE OUTPUT carefully.

Peter
OSR
@OSRDrivers

Peter,

thanks. Unfortunately the system does not generate a memory dump, although this is enabled.

The driver goes through the full load/unload cycle once, but something freezes the system such that I do not get a MEMORY.DMP in %SYSTEMROOT% once the driver loads for the 2nd time.

Automatically manage virtual space on disks is enabled. Kernel dump generation is enabled but no dump file gets written to disk.

Regards,

Leon.

I am trying to step towards the point where the system freezes, but I am facing another challenge, see below. What am I missing? The debugger does not seem to break at EvtDeviceAdd.

0: kd> bu lancero.sys!EvtDeviceAdd
0: kd> g

Lancero DriverEntry
Lancero Built Sep 28 2015 15:46:23
Lancero DriverEntry returns 0
Lancero EvtDeviceAdd(Driver=0x785915E8)
Lancero DriverUnload

Thanks,

Leon.

I suspect the driver is already loaded into memory, so there’s no load to trigger the bu resolution.

Try using bp instead of bu; if it is already present, the breakpoint will be set; if not, it will be converted to bu.

Also, are you absolutely sure that the name of the function you are trying to set the breakpoint on is correct?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-592000-
xxxxx@lists.osr.com] On Behalf Of xxxxx@sidebranch.com
Sent: 28 September 2015 17:24
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Hard crash after EvtDeviceAdd

I am trying to step towards the point where the system freezes, but I
am facing another challenge, see below. What am I missing? The debugger
does not seem to break at EvtDeviceAdd.

0: kd> bu lancero.sys!EvtDeviceAdd
0: kd> g

Lancero DriverEntry
Lancero Built Sep 28 2015 15:46:23
Lancero DriverEntry returns 0
Lancero EvtDeviceAdd(Driver=0x785915E8)
Lancero DriverUnload

Thanks,

Leon.
This email message has been delivered safely and archived online by Mimecast.

For more information please visit http://www.mimecast.com

xxxxx@sidebranch.com wrote:

thanks. Unfortunately the system does not generate a memory dump, although this is enabled.

The driver goes through the full load/unload cycle once, but something freezes the system such that I do not get a MEMORY.DMP in %SYSTEMROOT% once the driver loads for the 2nd time.

Automatically manage virtual space on disks is enabled. Kernel dump generation is enabled but no dump file gets written to disk.

Well, a system freeze is not a “crash”. Because of Turing’s stopping
problem, it can’t generate a dump.

One common cause of such a freeze is an interrupt storm. Does your
device generate interrupts? Are you registering an interrupt handler?
Are you properly disabling your interrupt during EvtInterruptDisable?

Does your DriverUnload wait for some condition before unloading?


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

That’s why I called it a “freeze” rather than a “crash”.

I had minimized my driver to not touch the hardware, other than mapping BARs. Even when removing this, the system still freezes. Yes the hardware has changed, but it does not pose problems under non-Windows operating systems.

I have reason to believe it is actually the debugger which is at fault here, and I will may need to double-check my setup in other thread.

I got a bit further. My breakpoint didn’t hit simply because I was using

0: kd> bu lancero.sys!EvtDeviceAdd

rather than

0: kd> bu lancero!EvtDeviceAdd

I found that the system freezes here:

Status = WdfFdoQueryForInterface(DeviceContextData->mWdfDevice,
&GUID_BUS_INTERFACE_STANDARD,
(PINTERFACE) &DeviceContextData->mBusInterface,
sizeof(BUS_INTERFACE_STANDARD),
1, // Version
NULL); //InterfaceSpecificData
if (!NT_SUCCESS(Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfFdoQueryForInterface failed 0x%X\n", Status);
return Status;
}

BytesRead = DeviceContextData->mBusInterface.GetBusData(DeviceContextData->mBusInterface.Context,
PCI_WHICHSPACE_CONFIG, //READ
&DeviceContextData->mPciCommonHeader,
FIELD_OFFSET(PCI_COMMON_CONFIG, VendorID),
PCI_COMMON_HDR_LENGTH);

which led me to this tip from Don Burn:

http://www.osronline.com/showThread.cfm?link=257481

“The resources are read for you by Plug and Play and provided in the EvtDevicePrepareHardware call. GetBusData has been obsolete and known to hang for over 10 years.”

which explains things.

Thanks for all the answers, now and in the past.


Leon.

Wait! Not so fast!

The GetBusData method on the bus interface structure is most certainly NOT obsolete, I can assure you of that. If it was, lots of people would be in big trouble.

If you keep reading that thread, you’ll see that Mr. Roberts points out that Mr. Burn was assuming the OP in that thread was calling HalGetBusData, which has indeed been obsolete for more than 10 years… more like 15 years at this point, actually.

So… the question comes down to:

a) Why are you calling GetBusData? Presumably you’re doing this to get resource data/info that isn’t present in the data presented in your EvtDevicePrepareHardware?

b) Why are you calling GetBusData at the point that you’re calling it? It is possible that calling the GetBusData from the bus interface isn’t happy to be called at EvtDriverDeviceAdd.

Peter
OSR
@OSRDrivers

Peter,

thanks for unfastening my seatbelt – I am again debugging the initial problem (system freezes on second load of the driver – but outside of the driver code). So my assumption is I am leaving the device or system in bad state after the 1st driver load/unload iteration.

I am not touching any device hardware (MMIO) to the BARs; I have disabled all MMIO related calls and any further driver functionality (mostly SGDMA).

To answer your question(s):

So… the question comes down to:
a) Why are you calling GetBusData?
Basically to find out on which bus/device/function we are (as, at the time, PCIe hardware needed to be debugged).

b) Why are you calling GetBusData at the point that you’re calling it?
I think I copied this code from a 2008-time reference driver but don’t ask me which one – so far for tracability. (Does that count…?)

It is possible that calling the GetBusData from the bus interface isn’t happy to be called at EvtDriverDeviceAdd.
Maybe, how can I find out about its unhappiness, and how it wants to be treated otherwise?

I will dump the EvtDeviceAdd() for you to grumble at:

/**
* Perform device initialization when a device is found by the PnP manager
*/
NTSTATUS EvtDeviceAdd(IN WDFDRIVER Driver, IN PWDFDEVICE_INIT DeviceInit)
{
NTSTATUS Status = STATUS_SUCCESS;
WDF_PNPPOWER_EVENT_CALLBACKS PnpPowerCallbacks;
WDF_POWER_POLICY_EVENT_CALLBACKS PowerPolicyCallbacks;
WDF_OBJECT_ATTRIBUTES FdoAttributes;
WDFDEVICE Device;
WDF_INTERRUPT_CONFIG InterruptConfig;
WDF_IO_QUEUE_CONFIG QueueConfig;
WDF_OBJECT_ATTRIBUTES Attributes;
WDF_FILEOBJECT_CONFIG FileObjectConfig;
PDEVICE_CONTEXT DeviceContextData = NULL;
WDF_DMA_ENABLER_CONFIG DmaConfig;

ULONG BytesRead = 0;
uint32 Index;

PAGED_CODE();

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, DRIVERNAME " EvtDeviceAdd(Driver=0x%p)\n", Driver);

#if 1
/* we prefer Direct I/O
*
* Direct I/O only works with deferred buffer retrieval
* No guarantee that Direct I/O is actually used
* Direct I/O is only used for buffers that are full pages
* Buffered I/O is used for other parts of the transfer
*/
WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoDirect);

// Set call-backs for any of the functions we are interested in.
// If no call-back is set, the framework will take the default action by itself.
WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&PnpPowerCallbacks);
PnpPowerCallbacks.EvtDevicePrepareHardware = EvtDevicePrepareHardware;
PnpPowerCallbacks.EvtDeviceReleaseHardware = EvtDeviceReleaseHardware;
WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &PnpPowerCallbacks);

WDF_POWER_POLICY_EVENT_CALLBACKS_INIT(&PowerPolicyCallbacks);
WdfDeviceInitSetPowerPolicyEventCallbacks(DeviceInit, &PowerPolicyCallbacks);

// ContextCleanup will be called by the framework when it deletes the device.
// So you can defer freeing any resources allocated to Cleanup callback in the
// eventEvtDeviceAdd returns any error after the device is created.
FdoAttributes.EvtCleanupCallback = EvtDeviceContextCleanup;

// Register file object call-backs
WDF_OBJECT_ATTRIBUTES_INIT(&Attributes);
Attributes.SynchronizationScope = WdfSynchronizationScopeNone;
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(&Attributes, FILE_CONTEXT);

WDF_FILEOBJECT_CONFIG_INIT(&FileObjectConfig, EvtDeviceFileCreate, EvtFileClose, EvtFileCleanup);
WdfDeviceInitSetFileObjectConfig(DeviceInit, &FileObjectConfig, &Attributes);

// Specify the context type and size for the device we are about to create.
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&FdoAttributes, DEVICE_CONTEXT);

Status = WdfDeviceCreate(&DeviceInit, &FdoAttributes, &Device);
if (!NT_SUCCESS(Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfDeviceCreate failed %d\n", Status);
return Status;
}

// Device creation is complete.
// Get the DeviceExtension and initialize it.
/* get the driver state context from the device */
DeviceContextData = GetDeviceContextData(Device);
/* reference from driver context to device */
DeviceContextData->mWdfDevice = Device;

#if 0
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP,
DRIVERNAME " PhysicalDevice=0x%p, Device=0x%p, Lower=0x%p, DevExt=0x%p\n",
WdfDeviceWdmGetPhysicalDevice(Device),
WdfDeviceWdmGetDeviceObject(Device),
WdfDeviceWdmGetAttachedDevice(Device),
DeviceContextData);
#endif

for (Index = 0; Index < 6; Index++) {
DeviceContextData->mBarPhysicalAddress[Index].QuadPart = 0;
DeviceContextData->mBarKernelVirtualAddress[Index] = NULL;
DeviceContextData->mBarLength[Index] = 0;
DeviceContextData->mBarIsMemory[Index] = FALSE;
}

DeviceContextData->mInterruptCount = 0;
DeviceContextData->mMyInterruptCount = 0;
/* the events device by default is only interested in user interrupts */
DeviceContextData->mEventsPendingMask = 0x0000FFFFUL;

#if 0
Status = WdfFdoQueryForInterface(DeviceContextData->mWdfDevice,
&GUID_BUS_INTERFACE_STANDARD,
(PINTERFACE) &DeviceContextData->mBusInterface,
sizeof(BUS_INTERFACE_STANDARD),
1, // Version
NULL); //InterfaceSpecificData
if (!NT_SUCCESS(Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfFdoQueryForInterface failed 0x%X\n", Status);
return Status;
}
#endif

/* configure interrupt handler for device interrupts */
WDF_INTERRUPT_CONFIG_INIT(&InterruptConfig, EvtInterruptIsr, EvtInterruptDpc);
/* set callbacks for enabling/disabling interrupts */
InterruptConfig.EvtInterruptEnable = EvtInterruptEnable;
InterruptConfig.EvtInterruptDisable = EvtInterruptDisable;

/* register interrupt handler */
Status = WdfInterruptCreate(DeviceContextData->mWdfDevice, &InterruptConfig, WDF_NO_OBJECT_ATTRIBUTES, &DeviceContextData->mWdfInterrupt);
if (!NT_SUCCESS (Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfInterruptCreate failed: 0x%X\n", Status);
return Status;
}

#if 0
Status = IoGetDeviceProperty(WdfDeviceWdmGetPhysicalDevice(Device),
DevicePropertyBusNumber,
sizeof(ULONG),
&DeviceContextData->mPciBusNr,
&BytesRead);
if (!NT_SUCCESS(Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " IoGetDeviceProperty (DevicePropertyBusNumber) failed\n");
return Status;
}

Status = IoGetDeviceProperty(WdfDeviceWdmGetPhysicalDevice(Device),
DevicePropertyAddress,
sizeof(ULONG),
&DeviceContextData->mPciFunctionNr,
&BytesRead);
if (!NT_SUCCESS(Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " - IoGetDeviceProperty (DevicePropertyAddress) failed\n");
return Status;
}
#endif
#if 0
// For PCI, the DevicePropertyAddress has device number in the high word and the function number in the low word.
DeviceContextData->mPciDeviceNr = (DeviceContextData->mPciFunctionNr >> 16) & 0x0000FFFF;
DeviceContextData->mPciFunctionNr &= 0x0000FFFF;

BytesRead = 0;
BytesRead = DeviceContextData->mBusInterface.GetBusData(DeviceContextData->mBusInterface.Context,
PCI_WHICHSPACE_CONFIG, //READ
&DeviceContextData->mPciCommonHeader,
FIELD_OFFSET(PCI_COMMON_CONFIG, VendorID),
PCI_COMMON_HDR_LENGTH);

if (BytesRead != PCI_COMMON_HDR_LENGTH) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " GetBusData failed [got %d instead of %d bytes]\n", BytesRead, PCI_COMMON_HDR_LENGTH);
return STATUS_INVALID_DEVICE_REQUEST;
}
#endif

// Tell the Framework that this device will need an interface so that applications can interact with it.
Status = WdfDeviceCreateDeviceInterface(Device, (LPGUID) &GUID_DEVINTERFACE_LANCERO, NULL);
if (!NT_SUCCESS (Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfDeviceCreateDeviceInterface failed with status %d\n", Status);
return Status;
}

/* accept multiple I/O request to run in parallel, they are sequentialized later */
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&QueueConfig, WdfIoQueueDispatchParallel);
/* callback handler for control requests */
QueueConfig.EvtIoDeviceControl = EvtIoDeviceControl;
/* callback handler for read requests */
QueueConfig.EvtIoRead = EvtIoRead;
/* callback handler for write requests */
QueueConfig.EvtIoWrite = EvtIoWrite;
/* create the default queue upon all I/O requests arrive */
Status = WdfIoQueueCreate(Device, &QueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &DeviceContextData->mBothQueue);
if (!NT_SUCCESS (Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfIoQueueCreate failed with status %d\n", Status);
return Status;
}

WDF_IO_QUEUE_CONFIG_INIT(&QueueConfig, WdfIoQueueDispatchSequential);
/* callback handler for event read requests */
QueueConfig.EvtIoRead = EvtIoReadEvents;
Status = WdfIoQueueCreate(Device, &QueueConfig, WDF_NO_OBJECT_ATTRIBUTES, &DeviceContextData->mEventsReadQueue);
if (!NT_SUCCESS (Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfIoQueueCreate failed with status %d\n", Status);
return Status;
}
/* this queue should not forward requests until we ask it to */
WdfIoQueueStop(DeviceContextData->mEventsReadQueue, NULL, NULL);

/* at least 8 bytes alignment */
WdfDeviceSetAlignmentRequirement(Device, 8 - 1);
WDF_DMA_ENABLER_CONFIG_INIT(&DmaConfig, WdfDmaProfileScatterGather64Duplex, MAX_TRANSFER_SIZE);

/* WDF DMA Enabler */
Status = WdfDmaEnablerCreate(Device, &DmaConfig, WDF_NO_OBJECT_ATTRIBUTES, &DeviceContextData->mDmaEnabler);
if (!NT_SUCCESS (Status)) {
TraceEvents(TRACE_LEVEL_ERROR, DBG_PNP, DRIVERNAME " WdfDmaEnablerCreate() failed with status %d\n", Status);
return Status;
}

#if 0
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, DRIVERNAME " Added device at Bus %u Device %u Function %u\n",
DeviceContextData->mPciBusNr, DeviceContextData->mPciDeviceNr, DeviceContextData->mPciFunctionNr);
#endif

TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, DRIVERNAME " EvtDeviceAdd() returns status %d\n", Status);
#endif
return Status;
}

As my problem exactly matches the earlier reference thread, I have searched for the topic starter and found this thread from the same poster:

http://www.osronline.com/showThread.cfm?link=259010

There are even more coincidences here: My PCIe device is an FPGA too, and identically it is powered through an external power supply.

The faulty behaviour seems identical.

I have some evidence now that it is related to:

  • reading configuration space. As I could single-step to the GetBusData() call, where the system froze.
  • power management. Windows leaves the device in different state than how it was after system reset. (i.e. the host hard reset or power-cycled.) Note that the FPGA is never power-cycled, only reset through the PCIE_RESET# signal.

I am not aware of the exact Dx states implemented in the endpoint, but the above indicates power management issues.

Really!? Well, that IS interesting. For my own education, can you explain to me the goal/thinking behind separately powering your device? In the previous case I thought we were dealing with a special case… but if this is a common design pattern, it’s something I’d like to understand.

Hmmm… I’m PRETTY sure that if the bus driver believes the device was put into D3 (and the bus driver presumes to know this, as he’s responsible for the device’s power plane), he assumes the device was power-on reset when it returns to D0. (what is that state… D0-Uninit, initially??).

Could that be part of what you’re seeing here?

Peter
OSR
@OSRDrivers

Hello Peter,

or

can you explain to me the goal/thinking behind separately powering your device? In the previous case I thought we were dealing with a special case… but if this is a common design pattern, it’s something I’d like to understand.

These are the big development boards that are used to bring up the first FPGA samples. They are loaded with electronics for characterisation. I am sure they want to power the board during all states in order to debug the hardware. I am not sure if the boards allow a manual override switching to bus powering, it is something I am to find out.

Also, I will be inspecting the end-point hardware regarding power management support details.

Hmmm… I’m PRETTY sure that if the bus driver believes the device was put into D3 (and the bus driver presumes to know this, as he’s responsible for the device’s power plane), he assumes the device was power-on reset when it returns to D0. (what is that state… D0-Uninit, initially??).

I have to read up on the PCIe spec about what is supposed to happen exactly.

Anyway, in any case I do not understand why it would cause a freeze during configuration cycle access.
Also, I am eager to learn why I haven?t seen this happen on other operating systems, such as Linux.

And third, I would love to be able to ask the original poster of the similar issue, but email addresses are hidden and replies are no longer possible as that thread is one year old.

Regards,

Leon.

On 29 Sep 2015, at 18:33, xxxxx@osr.com wrote:

Really!? Well, that IS interesting. For my own education, can you explain to me the goal/thinking behind separately powering your device? In the previous case I thought we were dealing with a special case… but if this is a common design pattern, it’s something I’d like to understand.

Hmmm… I’m PRETTY sure that if the bus driver believes the device was put into D3 (and the bus driver presumes to know this, as he’s responsible for the device’s power plane), he assumes the device was power-on reset when it returns to D0. (what is that state… D0-Uninit, initially??).

Could that be part of what you’re seeing here?

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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

Leon Woestenberg wrote:

The driver is KMDF with WDF. About Direct I/O: I am reading “with KMDF, drivers can opt-in for Direct I/O”. I have never understood if this guarantees something.

That determines whether IRP_MJ_READ and IRP_MJ_WRITE requests are
processed as buffered I/O (where the buffer is copied) or as direct I/O
(where the user memory is mapped into kernel space). That’s it. If you
don’t handle ReadFile or WriteFile requests, then the state doesn’t
really matter.


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

Thanks for the info on the use-case for self-powered devices. That makes sense. Much appreciated.

Well,that IS a good question. I would be more inclined to bet it’s some sort of deadlock (in other words, due to lock acquisition), as opposed to a hardware type thing. You walked into the function… Where did it hang?

Wondering why it works on Linux but not in Windows will drive you nuts. They really are very different operating systems, especially when it comes to power management.

In terms of inquiring of the original poster in that other thread (I seem to recall that we a used hi pretty well… His device didn’t support D3 or something). We only hide email addresses via the web interface. If you contact me off list, I can forward you his post and you can email him… HE doesn’t know you weren’t a list member when he posted (if you were, you’d have his email address). :wink:

Peter
OSR
@OSRDrivers

Hello Tim,

On 30 sep. 2015, at 00:45, Tim Roberts wrote:
>
> Leon Woestenberg wrote:
>> The driver is KMDF with WDF. About Direct I/O: I am reading “with KMDF, drivers can opt-in for Direct I/O”. I have never understood if this guarantees something.
>
> That determines whether IRP_MJ_READ and IRP_MJ_WRITE requests are
> processed as buffered I/O (where the buffer is copied) or as direct I/O
> (where the user memory is mapped into kernel space). That’s it. If you
> don’t handle ReadFile or WriteFile requests, then the state doesn’t
> really matter.
>
I am handling those. When I request Direct I/O, can I be sure that all user space transfers are actually mapped, including the possibly non-paged aligned head and tail? The comment in my driver, which is copied from some 2008-ish reference driver, mentioned that a transfer might be broken up into buffered and direct i/o. In my tests (win xp, 2k, 7) I have only seen direct i/o, including for head and tail.

I am not too worried there, I could not find any such remark in the MSDN documentation.

Thanks,

Leon

I had an interruption in delivery from OSR, and I just noticed this. I think you don’t use the .sys extension on the module name. IIRC, it would be:

0: kd> bu lancero!EvtDeviceAdd
0: kd> g

I hope my memory is serving properly this morning.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.http:</http:>
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant four consecutive years (2012-2015)
A CHAMPION in Info-Tech Research Group’s 2015 SIEM Vendor Landscape Report
SANS “Best of the Year” in SIEM, 2014
Perfect 5-Star Rating in SC Magazine (2009-2014)

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David Boyce
Sent: Monday, September 28, 2015 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] Hard crash after EvtDeviceAdd

I suspect the driver is already loaded into memory, so there’s no load to trigger the bu resolution.

Try using bp instead of bu; if it is already present, the breakpoint will be set; if not, it will be converted to bu.

Also, are you absolutely sure that the name of the function you are trying to set the breakpoint on is correct?

> -----Original Message-----
> From: xxxxx@lists.osr.commailto:xxxxx [mailto:bounce-592000-
> xxxxx@lists.osr.commailto:xxxxx] On Behalf Of xxxxx@sidebranch.commailto:xxxxx
> Sent: 28 September 2015 17:24
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Hard crash after EvtDeviceAdd
>
> I am trying to step towards the point where the system freezes, but I
> am facing another challenge, see below. What am I missing? The debugger
> does not seem to break at EvtDeviceAdd.
>
> 0: kd> bu lancero.sys!EvtDeviceAdd
> 0: kd> g
>
> Lancero DriverEntry
> Lancero Built Sep 28 2015 15:46:23
> Lancero DriverEntry returns 0
> Lancero EvtDeviceAdd(Driver=0x785915E8)
> Lancero DriverUnload
>
> Thanks,
>
> Leon.


This email message has been delivered safely and archived online by Mimecast.
For more information please visit http://www.mimecast.com



NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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

Google is your friend. The comment is a direct cut/paste from the MSDN documentation, and applies ONLY to UMDF V1.x – It’s not relevant, or even correct, for KMDF.

In a word, yes.

UMDF V1 treats Direct I/O rather differently from how KMDF (and WDM) treats Direct I/O…

Peter
OSR
@OSRDrivers

The hard freeze problem has been solved. It was not related to the driver source code.

There was a configuration signal in the endpoint hardware design that acknowledged power management requests. It was disabled, thereby probably no longer being PCIe compliant.

To summarize: ill-configured FPGA PCIe devices can cause a Windows system to hard freeze (no kernel dump, no blue screen) during configuration space access if during earlier power management requests (from D0 to D1+) the FPGA did not properly acknowledge the request.

Thanks for all the pointers and tips.

Leon


Leon Woestenberg
Sidebranch Embedded Systems
www.sidebranch.com
Lancero PCIe FPGA SoC IP
www.lancero.eu.com

Thank you for “closing the loop” on this, Mr. Woestenberg.

Glad to hear the problem is solved… and even happier to hear that it wasn’t some deep, dark, problem with Windows power management.

Peter
OSR
@OSRDrivers