InCD 3.5.x not allowing 98SE to reboot / shut down

[Traveller]

It's been a hell of a week. After solving a problem with EasyWrite Reader, I now get to have some fun with InCD 3.5.xx.x...!

Synopsis
I had Intel's Application Accelerator IDE drivers installed on my W98SE system for approx over a year without incident, until, that is, I installed the 3.x version of EasyWrite. Prior to EasyWrite, I had some ancient predecessor installed (which I completely forgot about, lol): InCDUDFReader (used bsudfrdr v2.04-200101181745).

Removing the IAA drivers resolved my problem with EasyWrite but in turn, created a problem with the InCD 3.5.xx.0 series (I tested 3.5.24.0, 3.5.22.0 & 3.5.19.1).

The problem is that W98SE no longer reboots / shuts down completely(I make it to the "Windows is shutting down" screen, than it hangs: upon reboot, Scandisk runs, indicating that indeed, Windows did not properly complete it's shutdown routine).

I tested InCD with the following uninstalled (or disabled):
EasyWrite
Adaptec ASPI 4.71(0002) (swapped out with 4.60)
Lexar USB-enabled Compact Flash drivers
Microsoft Backup Utility (=Seagate DRV*.VXDs)
scsi1hlp.vxd, atapchng.vxd, torisan3.vxd, necatapi.vxd

The only device drivers that are still in use are:
AIC78XX.mpd (Adaptec AVA-2904 SCSI-2 Host Adapter, used in conjunction with my scanners)
Fasttx2k.mpd, Fttkvsd.vsd & Pu66vsd.vsd (used by the ASUS P4PE's onboard Promise 376 Raid controller: I tried various driver versions as well.)
Misc. W98SE VXDs

There is only one exception to this failed shutdown problem: when a new "drive" is added to the system (eg. adding a removable drive, like my USB-enabled CF media), then shutdown proceeds normally - but for only one cycle (all further shutdowns are again problematic).

So, seven days into this & I have three options:
1. IAA + InCD 3.x - but no EasyWrite
2. Std IDE + EasyWrite - but no InCD
3. InCD4.x (which includes EasyWrite "technology") + full load on CPU all of the time.

As the Viennese would say, Na, das ist a Schass"

[Inertia]

Win98SE shutdown problems are common and well documented.

See the Microsoft advice at Problems Shutting Down Windows 98 Second Edition

and Windows 98 Shutdown Articles

[Traveller]

See the Microsoft advice at Problems Shutting Down Windows 98 Second Edition
and Windows 98 Shutdown Articles

Yes, thx, I know about it (been there, done that & been here too ).

But my point is that it only occurs when InCD 3.x is installed (& IAA is not) - otherwise I haven't had a shutdown problem since way, waaaay back when.

[KCK]

First, in connection with your other EasyWriteReader thread, are you telling us that you had InCDUDFReader installed all the time? Also not all the drivers mentioned in the other thread are listed now.

Why don't you simply list the current Iosubsys directory, and then comment on its drivers? Otherwise some drivers could be omitted again.

Concerning specific drivers, Atapchng.vxd, Torisan3.vxd and Necatapi.vxd aren't needed if you don't have an IDE CD changer, a Torisan 3 CD changer or an older (1x or 2x) NEC CD drive, respectively.

As for Drvwppqt.vxd and Drvwq117.vxd, you mentioned in the other thread that they weren't removed when MS Backup was uninstalled. I think it's safe to rename them.

However, I'm not so sure about the related driver Drvwcdb.vxd, since it's used not only by MS (Seagate/Conner) Backup, but also by parallel port scanners, etc.; still, apparently you may rename it as well.

It seems safe to rename Iomega.vxd, unless you have an Iomega tape or ZIP drive.

I'm not sure whether you need Scsi1hlp.vxd; most people don't, so I guess you could rename it as well.

As for ASPI, apparently you ran your tests with ASPI 4.60. Do you have a backup of the original ASPI for 98SE? If yes, you could try it as well. I'm not saying it should be better, it's just another factor.

The fact that shutdown is successful after a new drive is added means something strange is going on. My first bet would be that IAA wasn't removed cleanly. Perhaps you could install IAA on another 98SE box to monitor its registry changes. Otherwise, you could try running RegCleaner

http://www.vtoy.fi/jv16/shtml/regcleaner.shtml

Finally, let me add that I've not installed MS Shutdown Supplement on my 98SE box, but I did download all the critical patches, and my shutdown problems occur rarely (say, once in a month).

[Traveller]

1. ...you telling us that you had InCDUDFReader installed all the time? 2. not all the drivers mentioned in the other thread are listed now. 3. Why don't you simply list the current Iosubsys directory

1. No 2&3. Not all drivers are mentioned because I removed (renamed) them early on in the troubleshooting game, and here is my current InfoTool 2.0 report.

YES, the report's correct - I did re-install the IAAs to see if my shutdown problem is really related to the std 98 IDE Controller Drivers. Well, I couldn't believe my eyes, but the shutdown problem is still present!
I obviously changed someting or other during my troubleshooting process that has nothing to do with Microsoft vs. Intel IDE Controller... I did my best to retrace my steps, but was unable to determine any change that might affect shutdown.

I went a step further & analyzed various backed-up drivers & DLLs via Version Conflict Manager (VCM). I was shocked to find that there were a few VIP files where the backed-up version was of a newer version than the ones actually in use! This blew me away until I took note of the backup date, and realized it coincided with a HDD crash I experienced at the beginning of the year. I had no option but to "re-install" 98SE from the CD, and the Windows update feature appearantly did not "reset" 100%.

Some of the more interesting files include pci.vxd, vpowered.vxd, ifsmgr.vxd, msconfig.exe, vserver.vxd, msnet32.dll, and User.exe. After an extensive analysis, I determined that all the shutdown "delay" MS updates had been overwritten with the original 98SE CD files. I used the VCM utility to restore all but User.exe (I tried that one, boy, what a painful mistake that was, lol), but in the end, I still have my shutdown failure IFF InCD 3.5.x is installed. Sniff. Last but not least, I did a few bootlog tests, one with InCD installed & one w/o. Unfortunately this proved futile, as both logs were identical (except for the loading of the InCD-related drivers), and ended with the stmt EndTerminate = User and no Terminate/EndTerminate pair for Kernel.exe in sight.

I know what you're thinking - this calls for a clean re-install of 98SE + updates, and re-install of all apps & drivers. I agree! However... I have so many apps installed on this rig, including custom profiles for just about each one, that even after six month's worth of dilligent re-installing, I would never be able to recover everything.

Therefore, I propose that we bring this thread to a close, as it is now becoming more of a "How to fix my screwed-up OS" than an InCD problem. It just so happens that I was made aware of my system's state only upon installation of the recent InCD 3.5.x & EasyWrite versions.

The last "working" configuration I had then, was InCD 3.5.24.0 & InCDUDFReader 2.04: since I have no interest to roll that far back, I will concentrate on InCD4.x which actually runs on my "personalized" 98 SE rig InCD4 has it's problems, but like everyone else, I'll just wait it out.

Thanks to all, and to you in particular, KCK & sorry for wasting our time!

[Traveller]

Oh, and, last but not least...

As the Viennese would say, Na, das ist a Schass"

Ah... the only schass thing here is my own configuration! While it was my intention to state that my situation is FUBAR, I want to play it safe & make it clear that I never meant to imply that Ahead, or any of their products are directly responsible for the problems that I'm experiencing!
I've used several CD-R/RW apps and Ahead's products are by far my favorite

Keep it up, Ahead!

[KCK]

I agree that little can be done now without reinstalling 98SE.

As for InCD 4.0.1.0, did you check the CPU % utilization when InCD.exe is not running?

For InCD 3.x, InCD.exe was only needed for formatting; I'm not sure if it's the same for InCD 4.x, but you could try.

To this end, you may remove the InCD entry from your registry at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

or edit it to insert a leading semicolon (; ), so that it becomes ";C:\Program Files\Ahead\InCD\InCD.exe". For safety, you may export this key first to a .reg file in case you want to retrieve it later.

When needed, run InCD.exe from C:\Program Files\Ahead\InCD; later you may kill InCD.exe via Task Manager (Ctrl+Alt+Del).

This procedure is not recommended in general, since it doesn't prevent various InCD-associated services from running, and one must guess how long to wait before accessing a disc after inserting it in the burner.

[Traveller]

As for InCD 4.0.1.0, did you check the CPU % utilization when InCD.exe is not running?

Yeah, no difference. I'd like to keep the definition clear, however: it's not that InCD4.x is using any CPU time, it's that it's processes are somehow blocking W98SE's Halt-during-idle mode. In any event, there's no change, even when the InCD executable's not running (even when it's not started on reboot).

btw, I came across an interesting fact, regarding my shutdown issues. When I first installed the NEC ND1300A, I did some burning tests and backed up my root directory among other things. On that backup, I found two boot logs, one just before the install, one after. Well, the one before has a complete "Terminate/EndTerminate Kernel" pair, and the one after does not... In between the log's timestamps, only one other file was updated - mscdrom.pnf. Think I'm on to something here...

[Traveller]

Think I'm on to something here...

Well, I was on to something, but a totally different something!!! I'm documenting this in the event someone else comes across a similar problem. So here goes...

After all my messing around, there were in the end, only two actual facts:
1. Ahead EasyWrite Reader 3.x & Intel's IAA 2.3.x don't get along on a W98SE OS. If you try to install both, you are unable to reboot your OS.

2. NECATAPI.VXD may not just be for old NEC CD-ROM drives. The only reason I no longer had a clean shutdown/reboot is because I removed this driver!

As I mentioned in my last post, I had a bad feeling that my new ND1300A was at fault, because of the bootlog analysis. Well, I no longer believe this to be the case.

I finally came to the conclusion that you will only get a Terminate/EndTerminate pair for Kernel (as well as WIN32 & RIT pairs) when you completely shut down the PC. A bootlog from a simple reboot seems to end with the "User" Terminate/Endterminate pair. I didn't put this in my above "facts list" because I'm still not 100% certain if this is the case for all std W98SE installations (KCK, would you please consider checking this out on your own W98SE rig for me? Thx )

Having physically disconnected the ND1300A, I still suffered from bad shutdowns which sort of ruled it out as a suspect. Once I finaly discovered that I needed the NECATAPI driver, I started looking through my registry, still surprised that this ultra-new NEC device would require such an old VXD: what I found was that my floppy, a no-thrills 3.5" from a firm called ALPS was defined in the registry as GENERIC_NEC_FLOPPY_DISK. I called up google but couldn't find any association with NEC & ALPS. Still, I can find no other logical reason why the OS would need access to this ancient VXD, and I'm not even going to try to understand why this problem occurs only when EasyWrite is installed, lol!

None the less, I now have a clean shutdown & functioning InCD 3.5.24.0 as well as EasyWrite 3.x

I'd only wish that either Intel or Ahead would document the fact that IAA & EasyWrite have compatibility problems: both firms have an online troubleshooting FAQ, but neither of them mention anything about such a situation....

[KCK]

I ran a couple of tests on my 98SE box with InCD 3.52.40 and EasyWriteReader 3.3.2.0.

A bootlog from a run terminated by a reboot finishes with

EndTerminate = User

whereas for a run terminated by a shutdown it finishes with

EndTerminate = User
Terminate = KERNEL
Terminate = RIT
EndTerminate = RIT
Terminate = Win32
EndTerminate = Win32
EndTerminate = KERNEL

I also have GENERIC_NEC_FLOPPY_DISK in the registry. Normally I run the NECATAPI.vxd driver in order to stick to a standard configuration, but to check your suspicions I ran a couple of tests with NECATAPI.vxd renamed to NECATAPI.vx_. The only difference I noticed (both after reboots and shutdowns) was the disappearance in bootlogs of the two lines

[xxxxxxxx] Dynamic load device C:\WINDOWS\system\IOSUBSYS\necatapi.vxd
[xxxxxxxx] Dynamic load success C:\WINDOWS\system\IOSUBSYS\necatapi.vxd

No reboot or shutdown problems occured in all these tests.

Thus I can't confirm your finding that NECATAPI.vxd may be necessary for a standard floppy controller.

Note, however, that although you had physically disconnected the NEC drive before experimenting with NECATAPI.vxd, this needn't imply that your system was functioning exactly as if the NEC drive had never been connected. Maybe removing the NEC drive and allowing Windows to redetect all hardware would retrieve a cleaner configuration.

BTW, when I commented earlier on your removal of NECATAPI.vxd, I forgot that you had a NEC drive; thus, independently of generic advices, "NEC" should have rung a bell!

[Traveller]

KCK, thx a million for taking the time to do the A/B testing
(btw, why aren't you a moderator? You certainly put in enough time & effort to apply for the position

Ok, I agree that a VXD intended for NEC CD-ROMs would unlikely influence the system's Floppy drive(s), but I was all out of ideas! Looking @MSCDROM.inf didn't help much either. Even more confusing is the fact that the lack of the necatapi.vxd only affects the OS IFF InCD 3.x is installed.

But, hey, I've got no problem using the necatapi.vxd and I will also re-instate scsi1hlp.vxd as well as drvwcdb.vxd - just to play it safe!

...allowing Windows to redetect all hardware

All HW? How does one do that? The first time I physically disconnected the ND1300A only after removing it using Device Manager. The final test I did was to:
1. remove the ND1300A (via the Device Manager)
2. remove the Floppy
3. Checked the Registry for entries (none found, aside from Nero)
4. Renamed necatapi.vxd
5. Rebooted
I did the above because I thought that maybe without necatapi.vxd loaded, the OS might define the ND1300A (& Floppy) w/o using necatapi.vxd. But this didn't improve things, as I still experienced the shutdown issue.

The above is now purely academic: it makes little sense to analyze it further as a)necatapi.vxd is after all, an OS driver and b)it works! Time to concentrate on InCD 4.0.1.0, which is exactly what Ahead is doing. I'm certain as soon as the 4.x seires is more or less bug-free, the 3.x series will no longer be supported...

Again, thx KCK, for all the support - I very much appreciate it

[KCK]

You are welcome, Traveller!

I agree that your troubleshooting may be stopped, since you now have a working configuration of InCD 3.52.40 and EasyWriteReader 3.3.2.0.

Since nobody knows when InCD 4.x will become stable, it may be wise to try to ensure that you can revert to this working configuration after playing around with the next release of InCD 4.x. Here problems may arise if InCD 4.x doesn't uninstall cleanly.

To this end, you could monitor the system file and registry changes made by InCD 4.x. I can't recommend any utility for discovering file changes in C:\Windows (since I'm happy with an ancient Delta 3.0), but maybe other users could make suggestions. As for the registry, I'm using RegShot

http://www.regshot.ist.md/

Of course, it would have been best to run RegShot before installing InCD 4.0.1.0 for the first time, but it's a bit late for that!

[kaikow]

Ahead's EWR does cause problems in Win 98.

In the Adaptec/Roxio forum, I have a thread abot problems with Roxio's EWR in Win 98. I then postetd the following. Ahead's EWR causes severe problems in Win 98.

To see the full context of the message below, see my posting in the Adaptec/Roxio forum.
-------------------
The problem is definitely with Roxio EasyWrite Reader.

I have a license to use Nero on this system, so I uninstalled Roxio's EWR and installed Ahead's EWR 4.0.0.10.

As a result, I was able to read the MRW media in Win 98 on the CD-ROM drive.

However, as I expect that Ahead's EWR does not play nice with SimpliCD (installed in Win 98), when I ejected the CD-ROM, I got a BSOD and could not boot back into Win 98 without goiing into Safe Mode

Once in Safe Mode, I uninstalled the Ahead EWR and I was back to square 1 after re-installing Roxio's EWR.

So the problem is indeed with the Roxio EWR in Win 98.