IRQ Assignments and Boot Failure (VIA Appollo MVP3 & Win98)

I just installed a new motherboard (an Epox MP2 based on the VIA MVP3 Apollo chipset).  My old MB was also based on the VIA MVP3 chipset (it was an aopen ax59pro) so I did not anticipate problems ....

At first everything seemed to work.  But, when I checked system resources using msinfo32, I discovered that my cards were sharing IRQs left and right (not good!!).  I tried reinstalling the latest via drivers (including the miniport driver).  I tried reinstalling the VIA IDE drivers, and then tried disabling IDE altogether (I have a scsi only system).  Regardless, I couldn't seem to prevent my scsi controller from grabbing the same interrupt as my video card (disaster, I know!!).  

Anyway, despite this things seemed to be working alright, until I started to use my DV card (which strains all system resources).  The system just froze when I plugged in the firewire connection.    No problem, I thought, just reboot.

Since then, however, I have been unable to reboot into normal win98 (even after disconnecting the firewire cable).  The system freezes at different points, but always after the win98 logo screen (usually, it dies right after executing the win command -- I see only the messages from my path statement and antivirus scan (which complete successfully) on a black dos screen, then a bunch of disk activity then nothing; except sometimes I get a pure black screen with a blinking cursor, and other times I get all the way to a background windows 98 with a frozen hourglass).  I havew to use a hard reset at this point, btw.  I can boot into safe mode, but haven't been able to fix anything from there (have tried disabling and enabling IDE; resinstalling VIA IDE drivers; stepping through driver loading; compatibility mode disk access).  

I have also tried changing slots for my scsi controller, and assigning irq's to specific slots via bios (how does one assign an IRQ to AGP?  In any event this does not seem to solve the problem, though maybe I am doing it wrong; also, only four slots are reassignable, yet I have 5 pci, 2ISA and one AGP!!  Which is which in bios assignment which is merely numbered 1-4).

Assuming right to left numbering of slots, beginning with the first PCI slot (not counting AGP slot), my system is:

VIA Apollo MVP3/Epox MP2 with 11/30/99 BIOS
Number Nine SR9 AGP video (grabbing IRQ 15) (AGP)
Adaptec 2940U2W (grabbing IRQ 15) (Tried slots 1 and 2, currently in 2)
Canopus DVRaptor (slot 3; IRQ 11, as I recall -- note I can't tell since I can't boot windows 98 in normal mode, so the rest of the IRQ assignments are guesswork)
Trident 4DWave PCI soundcard (slot 5; IRQ 7 but sometimes 5)
3Com ISA PnP 3c509 etherlink card (ISA slot 2, set via driver to IRQ 10)

USB Controller (with Belkin Hub and Iomega USB Zip 250 -- I have tried disabling USB with no change):  IRQ varies
Com1: IRQ4

Note that:  com2 and lpt1 are disabled.  I use the lpt port via USB on the Belkin hub to connect to my printer, thus saving IRQ7.  

Also, note that last time I was able to boot to normal windows, I  had four free interrupts!! (and two interrupts being shared -- stupid stupid stupid win98)

Thanks in advance for any ideas!!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Asta CuTechnical consultant & graphic designCommented:
Is BIOS current, supports Plug and Play Operating System and is that setting correct?

You said all was OK until you checked msinfo32 to find IRQs being shared, this is OK (normally); depending on the resources.  My AGP card, for example, has memory requirements, but no IRQ.  

Off to meetings, but there's so much I want to say and help with here, perhaps later.

Troubleshooting Video Problems link:

Windows 98 How to and added links to help
jsnormanAuthor Commented:
Yes, the bios was dated 9/99 when I bought the board.  To attempt to rectify the problem, I updated (flash) to the newest 11/30/99 version on Epox's website.  It is PnP.  

I have two related Pnp options in BIOS:  (1) PnP Operating System?, and (2) Auto or manual IRQ assignment.  I have tried all four options (PnP O/S/not PnP OS x auto/manual).  None of these setting has enabled me to boot normally (though, I cannot say that I have tried all four settings with every other possible BIOS setting since there are too many to try).

I have also a setting to reserve an IRQ for VGA, and to reserve an IRQ for USB.  I have also tried enabling/disabling each of these to no avail.

It is strange that the SR9 video card insists on grabbing an IRQ; my previous video card that was also AGP did not want an IRQ, as you note.  Perhaps that is the problem?  How to keep the card from grabbing an IRQ though?

Sharing IRQ s can be okay, but not with high performance scsi and video applications.  DV/Firewire requires LOTS of bandwidth on both the disk and video buses.  So, I think any sharing there will cause me problems.  In any event, I would be HAPPY to be able to boot into win98 even with sharing of IRQs at this point (note that I can't even boot up anymore!!!).  

JS, first things first in order to resolve this. I get the distinct impression that you switched motherboards, but did you format the HD and reload the operating system? If not, you're asking for problems. When Win98 is installed, it creates a file called VMM32.VXD, which contains all of your bios data (static as well as dynamic) as well as all of the necessary virtual device drivers needed by the motherboard resources.

Let me know what you did when you installed the MB.
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

jsnormanAuthor Commented:
No; I have no desire to reformat my HD!!  Is there any way around reformatting the hard drive?  Can't I just tell Windows to recreate the vmm32.vxd file?  What if I delete it?

Since the MB uses the same chipset (MVP3) i did not think a reinstallation would be necessary?!  Must you also reinstall Windows whenever you flash the bios?
JS, I'll answer your questions in the order of your post.

<<I have no desire to reformat my HD!!  Is there any way around reformatting the hard drive?>>

You may have no other choice!

<<Can't I just tell Windows to recreate the vmm32.vxd file?>>

No, unfortunately you can't, unless you're willing to delete your entire \Windows folder, which means you'll be reloading your applications anyway, therefore a fresh format and install would be better.

<<What if I delete it?>>

This will render your system completely unbootable.

<<Since the MB uses the same chipset (MVP3) i did not think a reinstallation would be necessary?!>>

The same chipset is only a small portion of what the installer sees when building the vnn32.vcxd file. As ytou can see by the large number of problems you are having, Win98 believes that your system has one set of characteristics, while in fact there are several that it cannot see.

<<Must you also reinstall Windows whenever you flash the bios?>>

Flashing the Bios normally does not create these problems and Win98 will add missing virtual devices drivers to the \Windows\System folder beyond those written into in vmm32.vxd. However, if the bios update is a significant change beyond what the install found, you could run into the same problems and a reinstall would be recommended.

On a scsi based system this is more imperative than ide as your trying to improve performance. Although you may get most of these problems resolved, you will no doubt take a performance hit for the VXD's that cannot be changed.

I have found one way to get past this with about a 60% success rate, and that is through the registry. It will force Win98 to examine the VXD's present in the VMM32 file and compare them to the devices on the system starting with the Bios right on through to your monitor. Essentially what this means is that you will be reloading each and every device on your system to do this, but most of the time it works.

Open REGEDIT and drill down to:


and delete the entire enum key and then reboot. This will force Win98 to reload all of the devices.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
A bit less draconian step is to just rename vmm32.vxd to vmm32.old then run "setup /p f" from a dos prompt.

I know of renaming vmm32.vxd to vmm32.old then reinstall Windows 98.
Please explain the switches /p f
Thanks ( just learning )
Zombiwulf, there's nothing draconian about the suggestions. Furthermore, renaming VMM32.VXD serves absolutely no purpose used in conjunction with the setup /p f switches. As long as the installer can verify the existence of a usable registry, it will extract the base vmm32.vxd from the Win98 CD and use that, which in turn will result in missing VXD errors. As you know, or should know, the VMM32.VXD file is built only once, during the initial installation. You may want to refer to MSDN Developer News Windows 98 5/98 at Page 368.
jsnormanAuthor Commented:
WOW.  I have to admit, I am amazed.  It worked beatifully, all my IRQs are properly assigned (no sharing) and I can boot again.  Btw., I deleted both enums (I found one in the HKEY_CURRENT_CONFIG also).  

Upon rebooting (five times for driver installs) everything is working except my sound card, which I now believe to be defective (e.g., disabling the sound card and everthing is fine; it is a cheap Trident 4DWave sound card and I was thinking of moving up to SB Live! anyway).  

Thanks; this is a tip I am keeping around for a while (I upgrade motherboards on a regular basis :-) )

Glad its up and running "JSN"!

Yes, the base vmm32.vxd is extracted from the cab, but only if it isn't already present - if vmm32.vxd is present it will be used. The extracted vmm32.vxd is not the same as the final vmm32.vxd 'gumball' that is compiled during the setup process.

Since setup uses the detected system hardware to determine what vxd's will be compiled into the gumball, not renaming the vmm32.vxd after changing out a motherboard means that the OS may attempt to load incorrect vxd's from within vmm32.vxd.

My reference to 'draconian' was in response to your answer that the only way to generate a new vmm32.vxd was to delete the entire \windows folder - which would definitely be overkill.

Does rebuilding the vmm32.vxd always fix errors that refer to an inability to load vmm32.vxd or a corrupt vmm32.vxd? Nope. About half the time the problem is a vxd in \iosusbsys or \system that can't load and windows isn't sophisticated enough to report the actual source of the failed load.

Jsnorman: The /p f switches instruct the OS not to use the hardware portion of system.dat - in effect it does the same thing that clearing out the enum keys did.
Zombiwulf, what exactly is your point here. JSN changed a motherboard on a system with a pre-existing installation of Windows 98. So, the vnn32 file is comprised of the data developed based in part on the bios of the old board. You can use any of the setup switches you wish, including /p f, and nothing will change until you either "A" force a rebuild of that file, or "B" recreate the appropriate port of the registry.

The switch "/p", causes Setup to pass string(s) directly to Detection Manager (or sysdetmg.dll), and setup does not interpret the content of that string.

The "f" switch enables the clean registry mode and only forces "detection" to clean the root branch of the registry, as in HKEY_CLASSES_ROOT.

Neither has anything to do with ignoring the hardware portion of the registry.

Furthermore, there are no setup switches that cause windows setup to re-write the machine.inf without first eliminating the ENUM reg keys. At this stage a second machine.inf will be built known as machine2.inf.

As for Windows sophistication, if you are familiar with the bootlog.txt and the windows\system boot process, then you would also know that you can determine what virtual device drivers failed and where along the boot process the failure occurred.
My point is as stated previously. It is not necessary to delete the \windows\system directory to force a rebuild of vmm32.vxd.

End of thread.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.