Windows 7 - IRQ conflict

Asked By Yousuf Khan on 27-Jan-10 11:46 PM
Looks like I am having a good old fashioned IRQ conflict. Even though
IRQ's are theoretically shareable these days, in practice it may not be
such a hot idea. The problem first occurred after I replaced my
motherboard and processor on one of my systems, a couple of weeks back.
I was getting a BSOD once every couple of days. I have had 5 BSODs so far.
There has been 3 different types of Stop messages: variously involved
(twice), and the UNEXPECTED_KERNEL_MODE_TRAP (once) errors.

Initially, they involved TCPIP.SYS and IPNAT.SYS, both of which were
network-related. So I thought it is a network card issue and I updated
the Realtek Gigabit Ethernet driver, but that did not help.

Then a couple of days ago, I got another BSOD, but this time it involved
the driver NV4_MINI.SYS, which is an Nvidia video card driver -- seemed
completely unrelated. Then earlier today, I got another
DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL error, and this time it came from
both the TCPIP.SYS and the NV4_MINI.SYS drivers together! That clued me
into the idea that perhaps these two are sharing the same IRQ. I looked
in Device Manager, sorted it by Resource Connections, and sure enough
the gigabit ethernet and video card are both sharing IRQ 18! And that is
not all, there is 5 other devices sharing this same IRQ too! Seven
devices on the same IRQ line! There is only one other line, IRQ 16, that
has multiple devices on it too, at comparatively paltry 3 devices. Every
other IRQ line that is used only has one device on it, and there are
several empty unused IRQ lines all over the place.

So I went into the BIOS settings, but could not find any IRQ setting
functions available to it. The only option I found was something that
either enabled or disabled Plug'n'Play OS support, but not much else.

I tried to go into Windows' Device Manager to manually configure the
IRQ's, but the manual setting of resources was grayed out. According to
this webpage, you cannot manually set anything inside an ACPI-compliant PC:

automatic settings will be greyed out), this is usually related to the
ACPI function used by Win XP. "

So now I am stuck, is there isome kind of program available to reset the
ACPI tables? Some sections of the Registry that I can change?

Yousuf Khan

RobertVA replied to Yousuf Khan on 28-Jan-10 01:14 AM
Did you replace the motherboard and processor with the same make and
model numbers? If either was replaced with a different component, what
procedure did you use to reconfigure the OS to the new hardware
configuration (backup data and clean reinstall or repair install)?

Was the original (with the old hardware) installed by the computer
manufacturer? Customized OEM installation, generic "grey box" OEM, Full
retail OS or upgrade from an earlier version of Windows? Were the old
drivers installed from the OS installation media or media that came with
the hardware (graphic accelerator, Ethernet card, sound accelerator,
motherboard chip set etc)? Same information about driver sources after
replacing the hardware.

Others with similar hardware might be able to compare their driver
versions to yours if in a further post you list equipment descriptions
and any version numbers from the problematic computer. You may be able
to use software like the DirectX diagnostic, Windows System Information
or a third party hardware reporting tool to copy that information to a
text file or the Windows clipboard, allowing you to paste the relevent
sections of those report information into a post.
Yousuf Khan replied to RobertVA on 28-Jan-10 02:13 AM
Nope, both the motherboard and processor were upgraded to newer models.
The processor came from the same manufacturer, but is a generation or
two newer (AMD, old: Athlon 64 X2, new: Phenom II X3). The motherboard
is from the same manufacturer, but different models/chipsets (Asus, old:
M2NPV-VM/Nvidia Nforce 430, new: M4A785-M/ATI 785G).

The method used to reconfigure was closer to a repair install. It was
merely an install of the drivers for new components as they got
discovered Windows. Processor information drivers were updated to the
latest versions. All attached hardware have been completely matched to
appropriate drivers. There are no yellow exclamation points or red X's
among any of the Device Manager entries, if that is what you are getting at.

The machine is a home-built. It was completely built and upgraded by me
over the years. Windows XP was originally installed on this system as an
upgrade from Windows 2000, which must've been 7 or 8 years ago; it is
been upgraded between that time too. The old and new drivers were
installed by a combination of OS install media and hardware install
media. Some drivers had sources pre-included in the OS install disk, and
some came from a later hardware installation disk.

This latest motherboard and processor upgrade was actually quite smooth
and trouble-free, comparatively. All new hardware drivers were installed
and working in the first try, without incident.

You just needed to ask. Here is the full list of IRQ assignments on the

As you can see, there are 7 devices using the same IRQ 18.

Yousuf Khan
Jose replied to Yousuf Khan on 28-Jan-10 11:54 AM
=A0 =A0 =A0 =A0 =A0 =A0 System timer
=A0 =A0 =A0 =A0 =A0 =A0 Communications Port (COM1)
=A0 =A0 =A0 =A0 =A0 =A0 System CMOS/real time clock
=A0 =A0 =A0 =A0 =A0 =A0 =A0Microsoft ACPI-Compliant System
=A0 =A0 =A0 =A0 =A0 =A0 Numeric data processor
=A0 =A0 =A0 =A0 =A0 =A0 Primary IDE Channel
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard OpenHCD USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard OpenHCD USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Microsoft UAA Bus Driver for High Definition Aud=
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard Enhanced PCI to USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Realtek PCIe GBE Family Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard OpenHCD USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard OpenHCD USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard OpenHCD USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0PCI standard PCI-to-PCI bridge
=A0 =A0 =A0 =A0 =A0 =A0 =A0PCI standard PCI-to-PCI bridge
=A0 =A0 =A0 =A0 =A0 =A0 =A0NVIDIA GeForce 8600 GT
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard Enhanced PCI to USB Host Controller
=A0 =A0 =A0 =A0 =A0 =A0 =A0Standard Dual Channel PCI IDE Controller
Bob I replied to Yousuf Khan on 28-Jan-10 08:42 AM
You do not have an IRQ conflict, you have a bad driver for the hardware
installed. NT uses Virtual IRQs for legacy support and the number of
items listed on a particular IRQ is immaterial.
Yousuf Khan replied to Jose on 28-Jan-10 09:21 AM
Yes, that was mentioned in the original posting too.

From Device Manager and Everest.

The IRQ assignments.

Read the original post.

My main concern is to remove either the video card or ethernet port from
that sharing arrangement as those are the two that have caused most of
the Stop messages. I do not care if anything else is sharing resources.

Sorry, none of that information is relevant to this discussion. I will
show you the Resource Sharing/Conflict summary from Msinfo32 instead:

I/O Port 0x00000000-0x00000CF7	PCI bus
I/O Port 0x00000000-0x00000CF7	Direct memory access controller

I/O Port 0x00000060-0x00000060	Motherboard resources
I/O Port 0x00000060-0x00000060	Motherboard resources

I/O Port 0x000003C0-0x000003DF	PCI standard PCI-to-PCI bridge
I/O Port 0x000003C0-0x000003DF	NVIDIA GeForce 8600 GT

I/O Port 0x00000064-0x00000064	Motherboard resources
I/O Port 0x00000064-0x00000064	Motherboard resources

Memory Address 0xFEC00000-0xFEC00FFF	Motherboard resources
Memory Address 0xFEC00000-0xFEC00FFF	System board

IRQ 16	Standard OpenHCD USB Host Controller
IRQ 16	Standard OpenHCD USB Host Controller
IRQ 16	Microsoft UAA Bus Driver for High Definition Audio

Memory Address 0xD0000000-0xDFFFFFFF	PCI bus
Memory Address 0xD0000000-0xDFFFFFFF	PCI standard PCI-to-PCI bridge
Memory Address 0xD0000000-0xDFFFFFFF	NVIDIA GeForce 8600 GT

IRQ 18	PCI standard PCI-to-PCI bridge
IRQ 18	NVIDIA GeForce 8600 GT
IRQ 18	PCI standard PCI-to-PCI bridge
IRQ 18	Realtek PCIe GBE Family Controller
IRQ 18	Standard OpenHCD USB Host Controller
IRQ 18	Standard OpenHCD USB Host Controller
IRQ 18	Standard OpenHCD USB Host Controller

I/O Port 0x00000B00-0x00000B3F	Motherboard resources
I/O Port 0x00000B00-0x00000B3F	Motherboard resources

Memory Address 0xA0000-0xBFFFF	PCI bus
Memory Address 0xA0000-0xBFFFF	PCI standard PCI-to-PCI bridge
Memory Address 0xA0000-0xBFFFF	NVIDIA GeForce 8600 GT

I/O Port 0x000003B0-0x000003BB	PCI standard PCI-to-PCI bridge
I/O Port 0x000003B0-0x000003BB	NVIDIA GeForce 8600 GT

Memory Address 0xFA000000-0xFEAFFFFF	PCI standard PCI-to-PCI bridge
Memory Address 0xFA000000-0xFEAFFFFF	NVIDIA GeForce 8600 GT

No it will not. I have already been asked to repeat information that was in
the original posting, twice already.

Yousuf Khan
Yousuf Khan replied on 28-Jan-10 02:04 PM
Sure, but that is the way I have always done things. I find the whole idea
of Windows behaving differently depending on which method you used to
install it, somewhat troublesome. Why should a pre-existing installation
of Windows be unfixable compared to a freshly installed copy? it is the
same software in both cases.

I have been able to muddle through it in the past, and fix Windows when
most other people would have just reinstalled it.

I am also trying to buy a corporate copy of Windows 7 soon, so all this
might be moot soon. I will have no choice but to reinstall the OS from
scratch in that case. So I do not really want to reinstall XP from
scratch now, only to do it again with Win7.

it is certainly something to try. By comparison, I have had Linux installed
on this same machine for nearly as long as I have had XP, and it is not
been reinstalled either. However, it is behaving much better, it is
managed to reassign the ethernet to a different IRQ (27). There is also 3
fewer devices sharing IRQ 18 under Linux than under Windows. Here is the
Robert Myers replied to Yousuf Khan on 28-Jan-10 05:03 PM
I have always assumed that Windows checked certain things having to do
with the motherboard only on install.  I also assume that is by design,
since Microsoft thinks you have to buy a new OEM edition for every new

archmag replied to Yousuf Khan on 28-Jan-10 04:40 PM
Have you run memtest86/memtest86+ or some other memory tester?

Nate Edel                     
preferred email  |
is "nate" at the | "I do have a cause, though.  it is obscenity. I am
posting domain   |  for it."
archmag replied to Yousuf Khan on 28-Jan-10 04:43 PM
Well, you COULD do a XP/Vista/Win7 upgrade.  I do not think it is recommended.

Linux does much more sensible things about hardware detection and
initialization; for the most part, it is dynamic, and can get moved
between hardware FAR more easily than windows.

Nate Edel                     
preferred email  |
is "nate" at the | "I do have a cause, though.  it is obscenity. I am
posting domain   |  for it."
Trent replied to Yousuf Khan on 29-Jan-10 05:56 AM
Have you tried this?:

Make a .cmd file with the following:
set devmgr_show_nonpresent_devices=1

Run the created .cmd file

Go into device manager, select view, "Show hidden devices" and uninstall
all the devices that you believe to be in conflict. Also, uninstall all
the phantom devices - they will be the ones that are grayed out.

Reboot and go into BIOS setup. Under PnP/PCI configurations see if there
is something like "reset configuration data" if there is, set it to
enabled. Save and re-boot. Windows should re-enumerate all the deleted
devices that are still present in the system and (hopefully) correct the
Yousuf Khan replied to Trent on 29-Jan-10 07:16 PM
Thanks, no I had not tried that yet, and now that you reminded me, I
remember having seen this years ago, so it was a good idea to try.

However, it did not help, even after removing all phantom devices, and
even some of the live devices, the live devices just got re-detected and
put right back in their original slots.

There was not anything like that in the BIOS.

Yousuf Khan
Yousuf Khan replied to archmag on 01-Feb-10 06:59 PM
I just removed my Nvidia video card, since it was one of the sources of
the crashes. I am now using the integrated ATI video to see if the
integrated video will be assigned to a different IRQ, looks like Windows
is hell-bent on assigning this thing to IRQ 18, no matter what. Linux on
the other hand properly assigned it out to a completely different IRQ
(27), than the ethernet or the previous video card was on.

Strange thing is that prior to driver installation, Windows just assumes
it as a standard VGA adapter. This was the case with both the onboard
ATI and the discrete Nvidia. While it was an assumed VGA, it was
assigned to IRQ 10. After the proper drivers were installed, beit ATI or
Nvidia, the device automatically gets assigned IRQ 18. Who came up with
this no manual adjustment possible on ACPI crap?

Yousuf Khan
Bob I replied to Yousuf Khan on 02-Feb-10 08:41 AM
You are still barking up the wrong tree. You have driver issues, NOT
Yousuf Khan replied to Bob I on 02-Feb-10 11:37 AM
That's the nuttiest explanation I have heard yet. IRQ's are not a "legacy"
item. They are most definitely still used, it is the only way a
peripheral can get the attention of the processor, without needing the
processor to constantly poll it.

Yousuf Khan
Bob I replied to Yousuf Khan on 02-Feb-10 11:59 AM
A general description of IRQ sharing in Windows XP
neil replied to Yousuf Khan on 02-Feb-10 12:47 PM
If I were you I would carry out an inplace upgrade (repair install) then use
the motherboard driver disk to install the chipset drivers.

Yousuf Khan replied to Bob I on 02-Feb-10 04:06 PM
Yes, this is one of the articles I read that basically said that ACPI
does not allow you to change IRQ settings. But I am trying to find out if
somebody knows of a utility that will allow you to manipulate the ACPI
assignment tables.

Yousuf Khan
Yousuf Khan replied to neil on 22-Feb-10 01:08 PM
Yeah, it looks like that is the only solution for XP. However, now I am in
the process of upgrading some machines on my network to Windows 7, and
it looks like this odd behaviour of XP's is gone. There is hardly any
shared IRQ's in Windows 7, and there are hundreds of IRQ's available to
it too.

Yousuf Khan
Frank Pelle replied to Yousuf Khan on 22-Jul-10 12:31 AM
The Good, The Bad, and the Ugly

Lets start with the UGLY... The ugliest part of this entire issue is that of MISINFORMATION... People, If you are unsure of the answer, please do NOT contribute a theory that doesn't work. I am referring to the statement about drivers and updating them. You might as well tell the poor guy to change the case fan and buff out the optical drive...ridiculous. It has no bearing on the issue whatsoever.

The BAD, the bad news is a lot of people have actually had this issue (not uncommon) and tried to deal with it by doing feasible and legit things such as CHANGE BIOS SETTING, ACPI, UPGRADE TO NEW O/S. In short- there are issues with these theories so they don't always work. BIOS setting changes can do a round about tweak and with a little luck, they just may reduce the # of IRQ issues... but if your BIOS is an OEM board (HP DELL TOSHIBA) you're screwed because you don't have the advanced options. ACPI swapping to manual has to be done per core and sometimes is irreversible thus paralysing the O/S... UPGRADING to a new O/S is quite honestly NEVER a good idea. Clean installs are the way to go without inheriting problems and creating incompatibility issues. I must say- BOO to Windows for this move- If they want ACPI and their half-assed O/S to manage IRQs- then build something in the O/S / HAL to do so... Make it another built in MS if we don't have enough.

The Good,

You have to think of our overall objective and how much pain and anguish and time you have wasted in getting to your resolution. Its probably been a good 12+hrs of reading this crap and shooting wildly in the dark. My advise to you is back everything up in your profile onto a small NAS Unit. upgrade the bios, then wipe the HDD clean, and yes REINSTALL Windows...It gets better... When you do reinstall XP, make dam sure you reboot after every single driver is loaded so no IRQ gets "piggybacked" - yes that IS how it happens- so don't be such a multitasking impatient hothead- get the o/s right the 1st time...Do updates afterward- perform your tweaks to the O/S and ultimately... when you're satisfied...Ghost it onto a 40gb drive and put the copy away. Now you can migrate all your goodies and personalize it as you wish- If someday you have the same issue or get a nasty replicating virus then wipe that sucker clean and ghost the image back/ migrate your saved goodies back from the NAS again. I hope this changes your perception on how to handle your PC issues in the future. CIAO and God Bless!
Frank Pelle replied to Yousuf Khan on 22-Jul-10 12:41 AM
Wow, It is ridiculous, but what a wonderful dream it would be- to actually have the flawed architecture revamped and start fresh without the IRQ BS limitations