I'm afraid I didn't have a lot of luck with regedit in DOS.
It seemed to work OK to delete a key, but I couldn't import the key I wanted to import from the other Windows 98 installation with working sound.
It went through the motions of importing it, with a count from zero up to 100%, but as soon as it got to 100% a message came up saying - "Couldn't import enum.reg: Error accessing the registry."
I made sure that system.dat and user.dat had their read-only and hidden attributes off, but it made no difference.
It certainly deleted the enum key OK, judging by the mess I was greeted with when I rebooted, but it would not import the replacement key that I wanted it to.
Presumably it will
import registry data from another Windows 98 installation?
The only thing I could think of that might have made the new data incompatible was that the new installation was installed to the default C:\Windows folder, and my original is in C:\WIN-98.
I can't see any path specific data in that registry key though.
So, I gave up on that, and tried again just removing the enum and config keys and letting everything install again.
I also this time deleted the two .bin files from the INF folder.
After a huge amount of messing around I was back where I was before.
The system absolutely refuses to allocate a working configuration to the sound hardware.
I even un-ticked the "automatic" option on its resources tab, and then found that it was now apparently on IRQ 11.
I had written down the resources being used on the working system, which was also IRQ 11, but some of the Memory Ranges and I/O Ranges were different.
I changed them so the information in the resources tab was absolutely identical to that on the working system, and still the drivers refused to load and no sound!
All the other hardware can be made to work fine.
I really am puzzled completely by this now.
I think that we're perhaps looking in the wrong place by playing with the registry.
If you remember, I did restore a very old copy of the registry, from long before this problem appeared, and nothing at all changed.
I suspect that the problem isn't being caused by anything in the registry in that case.
We know now that it's not an actual hardware fault, as it works fine with the new installation.
So where does that leave us?
Surely it can only now be a configuration error somewhere that isn't
stored in the registry, or a system file problem.
Are there any files associated with NUSB that could conceivably cause this sort of problem?
I think I've got rid of them all now and restored the originals of any that NUSB replaced, but you never know, I could well have missed one or more!
Edited by Dave-H, 12 November 2009 - 07:51 PM.