IoConnectInterrupt fails after driver is updated

NTDEV
1

During driver development on multi core machine with XPSP2:

  1. At some point I have a driver that connects to an interrupt and receives it.
  2. I disable the driver, it calls IoDisconnectInterrupt.
  3. I modify the source and build the driver.
  4. From device manager I perform Update Driver.
  5. But now when the driver calls IoConnectInterrupt it fails with STATUS_INVALID_PARAMETER.

So I have to reboot after each source update.

Any ideas why this happens? Is there some sort of cleanup that I am not doing that is left from the previous driver?

2

STATUS_INVALID_PARAMETER is about all IoConnectInterrupt ever returns.
Not very helpful huh?

Sometimes looking at device manager sorted by resource usage helps,
especially if you know what resources your device was using in its
previous incarnation.

Why did you perform step 2 " I disable the driver, it calls
IoDisconnectInterrupt."?

You should just be able to skip right to step 3 and 4 - update the
driver without disabling it. This will do a query remove/remove, unload,
load, add device star device.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, March 27, 2007 10:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoConnectInterrupt fails after driver is updated

During driver development on multi core machine with XPSP2:

  1. At some point I have a driver that connects to an interrupt and
    receives it.
  2. I disable the driver, it calls IoDisconnectInterrupt.
  3. I modify the source and build the driver.
  4. From device manager I perform Update Driver.
  5. But now when the driver calls IoConnectInterrupt it fails with
    STATUS_INVALID_PARAMETER.

So I have to reboot after each source update.

Any ideas why this happens? Is there some sort of cleanup that I am not
doing that is left from the previous driver?

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

It seems to work fine now.
I added to the handling of IRP_MN_REMOVE_DEVICE a call to PoSetPowerState that sets the device power state to D3.

4

Calling PoSetPowerState (in any context) will not affect the interrupt state or the HAL’s tracking of the connection state. Some other change you made in the driver fixed the problem.

d

5

Yes, you are right. I tried commenting this out and it still worked.