asdf53 wrote on 2025-11-11, 06:34:

I just tested this and you're correct. This seems to be a problem with OllyDbg, it can attach, but not un-attach from a process, […]
Show full quote

DustyShinigami wrote on 2025-11-10, 17:45:

Yep, Memory Access Violation is checked. It'll let me minimise whilst it's playing, but as soon as I close, everything disappears from the desktop and I have no choice but to restart the PC. I'm guessing Explorer would need to be unloaded...? If I hit File > Exit, I get a warning about it not clearing up leftovers and if I'm sure I want to close. I imagine the same thing will happen if I accept.

I just tested this and you're correct. This seems to be a problem with OllyDbg, it can attach, but not un-attach from a process, the only option is to kill the process, which in case of a critical process such as explorer.exe seems to soft-lock the system. But in your scenario I don't see a problem, because you have to keep OllyDbg running anyway if you want to detect the error.

The other problem is, I don't believe, if and when the error triggers on startup, that it'll trigger OllyDbg. I get the impression I have to initialise Olly first. The error never pops up at random whilst I'm using the PC. Only at random during boot. On one occasion the PC booted, Filemon listed everything to do with XIT, but despite none of the associated files to do with it being found, the error never showed.

That makes it tougher, but there's still a chance. As long as the "xit" error message box is on screen, the process that called it is still in memory. So you might be able to just wait until it pops up, then run OllyDbg and attach to explorer.exe, go to ShellExecuteEx in memory, but this time, set the breakpoint at its end, not at the start. This is where it'll jump to right after you close the message box. If you then follow the process step by step, it should return to the memory region that called it, and from the memory region, you might be able to infer the DLL. It's just an idea so far, but I'll see if that's possible.

When I did trigger xit to test it these were the associated files it showed:

If you trigger the "error" yourself that won't tell you anything useful, because in that case, it's behaving just like it should. That was just to see if the breakpoint is working, which it is - nice.

Okay. It hasn’t done it for a little while, but as soon as it does, I’ll try and set it up at the end. It’s just odd how Filemon lists everything associated with xit as ‘Not Found’ on startup, but the error doesn’t always trigger.

One thing I’ve noticed is if I’ve been in DOS first and then exit and load up Windows, the xit error pops up every time, I think.

asdf53 wrote on 2025-11-11, 06:34:

I just tested this and you're correct. This seems to be a problem with OllyDbg, it can attach, but not un-attach from a process, […]
Show full quote

DustyShinigami wrote on 2025-11-10, 17:45:

Yep, Memory Access Violation is checked. It'll let me minimise whilst it's playing, but as soon as I close, everything disappears from the desktop and I have no choice but to restart the PC. I'm guessing Explorer would need to be unloaded...? If I hit File > Exit, I get a warning about it not clearing up leftovers and if I'm sure I want to close. I imagine the same thing will happen if I accept.

I just tested this and you're correct. This seems to be a problem with OllyDbg, it can attach, but not un-attach from a process, the only option is to kill the process, which in case of a critical process such as explorer.exe seems to soft-lock the system. But in your scenario I don't see a problem, because you have to keep OllyDbg running anyway if you want to detect the error.

The other problem is, I don't believe, if and when the error triggers on startup, that it'll trigger OllyDbg. I get the impression I have to initialise Olly first. The error never pops up at random whilst I'm using the PC. Only at random during boot. On one occasion the PC booted, Filemon listed everything to do with XIT, but despite none of the associated files to do with it being found, the error never showed.

That makes it tougher, but there's still a chance. As long as the "xit" error message box is on screen, the process that called it is still in memory. So you might be able to just wait until it pops up, then run OllyDbg and attach to explorer.exe, go to ShellExecuteEx in memory, but this time, set the breakpoint at its end, not at the start. This is where it'll jump to right after you close the message box. If you then follow the process step by step, it should return to the memory region that called it, and from the memory region, you might be able to infer the DLL. It's just an idea so far, but I'll see if that's possible.

When I did trigger xit to test it these were the associated files it showed:

If you trigger the "error" yourself that won't tell you anything useful, because in that case, it's behaving just like it should. That was just to see if the breakpoint is working, which it is - nice.

How would I set the breakpoint at the end? Is the command different or is it the same as before?

DustyShinigami wrote on 2025-11-11, 17:37:

How would I set the breakpoint at the end? Is the command different or is it the same as before?

When the error appears, keep the message box open. Run OllyDbg, attach to Explorer.exe, View>Executable modules, double click shell32. Press CTRL+N and find ShellExecuteExA in the list. Click it once to select it. Right click and sort by Address. Double click the address below ShellExecuteExA (it's named something like #51 on my machine). In the code view, scroll up about 10 commands until you find a RETN command. This is the end of ShellExecuteExA. RIght click it and set a breakpoint there (no conditional breakpoint). Then drag the OllyDbg window to the side and click OK on the xit error. When the breakpoint hits, open View>Call stack.

I recommend doing a test run before to see if your breakpoint works using the Start>Run as... method. Remember you need to click play when the breakpoint hits (might happen twice) to resume explorer.exe.

asdf53 wrote on 2025-11-11, 19:02:

DustyShinigami wrote on 2025-11-11, 17:37:

How would I set the breakpoint at the end? Is the command different or is it the same as before?

When the error appears, keep the message box open. Run OllyDbg, attach to Explorer.exe, View>Executable modules, double click shell32. Press CTRL+N and find ShellExecuteExA in the list. Click it once to select it. Right click and sort by Address. Double click the address below ShellExecuteExA (it's named something like #51 on my machine). In the code view, scroll up about 10 commands until you find a RETN command. This is the end of ShellExecuteExA. RIght click it and set a breakpoint there (no conditional breakpoint). Then drag the OllyDbg window to the side and click OK on the xit error. When the breakpoint hits, open View>Call stack.

I recommend doing a test run before to see if your breakpoint works using the Start>Run as... method. Remember you need to click play when the breakpoint hits (might happen twice) to resume explorer.exe.

Great. Thanks. 😁 I'll give it a shot a bit later.

Just to make it clear: After setting the breakpoint, click resume, then click OK on the error. When the breakpoint hits it'll pause again, keep it paused when viewing the call stack and making a screenshot.

When I said "you need to click play when the breakpoint hits", that only goes for the test run, because there's no point in pausing and analyzing the call stack.

The idea is to keep the debugger paused when setting up breakpoints and analyzing code, and clicking resume whenever you need to interact with the OS, in this case to click OK on the error dialog.

asdf53 wrote on 2025-11-11, 19:02:

RIght click it and set a breakpoint there (no conditional breakpoint).

Is this the same command as before or can anything be put there?

DustyShinigami wrote on 2025-11-12, 00:46:

asdf53 wrote on 2025-11-11, 19:02:

RIght click it and set a breakpoint there (no conditional breakpoint).

Is this the same command as before or can anything be put there?

Right click > Breakpoint > Toggle (F2). It shouldn't ask for any input. Then click resume and press OK on the xit error.

asdf53 wrote on 2025-11-12, 03:38:

DustyShinigami wrote on 2025-11-12, 00:46:

asdf53 wrote on 2025-11-11, 19:02:

RIght click it and set a breakpoint there (no conditional breakpoint).

Is this the same command as before or can anything be put there?

Right click > Breakpoint > Toggle (F2). It shouldn't ask for any input. Then click resume and press OK on the xit error.

Yeah, I don't think this is working right. Even before all of this is set up, it says Terminated in red in the bottom right corner. Pressing Play doesn't do anything and still says Terminated. And likewise if I click OK on the error box.

EDIT: Okay, I think it's because I was using an attempt saved under Recents. Did everything from scratch by attaching Explorer again. This is all I get in the call stack:

Okay, I don't think the approach of hooking into the process after the error message appears is going to work. The relevant memory contents (the function call arguments) seem to be already gone at that point. At that point, I'm out of ideas, at least using the debugger. Maybe there's a way, but that's beyond my limited expertise.

Another thing you could try is, if you're able to somewhat consistently provoke the error: Download Autoruns 8.61, and disable all non-MIcrosoft entries one by one and see if any of them makes the error disappear.

Do you have any removable media inserted (USB, CD or virtual CD drives)? Remove/unmount them and see if that makes a difference.

Finally, the brute-force approach would be to reinstall Windows and start with an unmodified stock system, then install components one by one to see what triggers the error. But that's going to be useless if the error only appears on a random basis.

asdf53 wrote on 2025-11-15, 10:46:

Okay, I don't think the approach of hooking into the process after the error message appears is going to work. The relevant memo […]
Show full quote

Okay, I don't think the approach of hooking into the process after the error message appears is going to work. The relevant memory contents (the function call arguments) seem to be already gone at that point. At that point, I'm out of ideas, at least using the debugger. Maybe there's a way, but that's beyond my limited expertise.

Another thing you could try is, if you're able to somewhat consistently provoke the error: Download Autoruns 8.61, and disable all non-MIcrosoft entries one by one and see if any of them makes the error disappear.

Do you have any removable media inserted (USB, CD or virtual CD drives)? Remove/unmount them and see if that makes a difference.

Finally, the brute-force approach would be to reinstall Windows and start with an unmodified stock system, then install components one by one to see what triggers the error. But that's going to be useless if the error only appears on a random basis.

Thanks for all your help and suggestions though. But yeah, it’s looking likely this might be here to stay. After I reformatted, the issue came straight back, so that’s not likely going to help. 😅 I did create an image right after making a fresh install, too.
The error always triggers at random during a regular boot. More often than not, the issue doesn’t appear. But the sure fire way of triggering it is to go into true DOS and then exit that back into Windows.
I do have a USB adapter plugged in at all times, to save me having to pop my pen drive into the back of the PC every time. So whether that’s causing it… I’ll try removing it and see if that triggers it. But apart from that, no other mounted devices are plugged in/enabled. Unless I leave a CD image mounted.

But I’ll give the Auroruns a try as well. 🙂

I know my hotplug icon for Safely Remove Hardware always comes back after a fresh install of Windows with the USB drivers installed. But once some big driver change happens, like the drivers for my Sound Blaster, it causes it to completely disappear from the taskbar.

The USB stuff could be worth investigating. ShellExecuteEx is also triggered when opening a directory, for example, each time you open a new folder in "My computer". This is because it's also used to "execute" a folder, i.e. opening it to display the contents. So if there's something that causes explorer to read a directory from a drive it can't access, or a "ghost" drive that's not actually present, this could also trigger the error.

The debugger would have been nice in that case because it would have shown you the drive that the file/folder opening attempt originated from. ShellExecuteEx has an argument "lpDirectory" that contains the working directory.

You're using the third-party USB drivers that overwrite the standard USB drivers, right? You could try reinstalling Windows 98 without the USB drivers first and install them later to see if they cause the error.

Or try disabling everything in device manager under "Universal serial bus controllers" to temporarily disable everything USB, this might also do the trick without having to reinstall.

Since you've had some disk corruption earlier (incorrect size on one of your partitions), it would also be a good idea to run scandisk on all your hard drives to make sure there's no file system corruption.

asdf53 wrote on 2025-11-15, 12:30:

The USB stuff could be worth investigating. ShellExecuteEx is also triggered when opening a directory, for example, each time you open a new folder in "My computer". This is because it's also used to "execute" a folder, i.e. opening it to display the contents. So if there's something that causes explorer to read a directory from a drive it can't access, or a "ghost" drive that's not actually present, this could also trigger the error.

The debugger would have been nice in that case because it would have shown you the drive that the file/folder opening attempt originated from. ShellExecuteEx has an argument "lpDirectory" that contains the working directory.

You're using the third-party USB drivers that overwrite the standard USB drivers, right? You could try reinstalling Windows 98 without the USB drivers first and install them later to see if they cause the error.

Yeah, it sure would be nice to find out what it’s related to.

I’m using the NUSB ones, I believe…? I can’t remember if they’re 3.5…? I think the latest one is 3.6, which are a bit buggy apparently. I think the image I made was after I’d installed them. 😬 But I would need to check. But yes, certainly worth trying to install them later, though I usually always need my saved drivers, software, and game patches I’ve accumulated. At some point I will look at getting some CD-RWs, that way I can keep adding and taking stuff off via CD.

asdf53 wrote on 2025-11-15, 13:11:

Or try disabling everything in device manager under "Universal serial bus controllers" to temporarily disable everything USB, this might also do the trick without having to reinstall.

Since you've had some disk corruption earlier (incorrect size on one of your partitions), it would also be a good idea to run scandisk on all your hard drives to make sure there's no file system corruption.

Yeah, I've removed the USB device and tried disabling everything to do with the USB, but it still pops up. So it's clearly not related to the USB device/controller. Also, scandisk comes back fine with all three HDDs.

asdf53 wrote on 2025-11-15, 10:46:

Okay, I don't think the approach of hooking into the process after the error message appears is going to work. The relevant memo […]
Show full quote

Okay, I don't think the approach of hooking into the process after the error message appears is going to work. The relevant memory contents (the function call arguments) seem to be already gone at that point. At that point, I'm out of ideas, at least using the debugger. Maybe there's a way, but that's beyond my limited expertise.

Another thing you could try is, if you're able to somewhat consistently provoke the error: Download Autoruns 8.61, and disable all non-MIcrosoft entries one by one and see if any of them makes the error disappear.

Do you have any removable media inserted (USB, CD or virtual CD drives)? Remove/unmount them and see if that makes a difference.

Finally, the brute-force approach would be to reinstall Windows and start with an unmodified stock system, then install components one by one to see what triggers the error. But that's going to be useless if the error only appears on a random basis.

Just tried Autoruns, too. Disabled everything that's non-Microsoft - still pops up. ^^; Bloody mystery. So maybe it is a Microsoft thing...?

You could change your shell from explorer to something else, like good old progman.exe, or something third party like bb4win. You could even boot straight into Olly and go from there... Anyways, the idea is to hopefully get the system up without starting explorer.exe at all. At this point you could, for example, open and prepare Filemon and Olly and leisurely launch a debug-attached explorer instead of having to time anything. Or if you still get the message when the new shell starts, at least you know it's not specifically explorer's fault.

> I've removed the USB device and tried disabling everything to do with the USB, but it still pops up. So it's clearly not related to the USB device/controller.

Maybe not a device or the controller, but your system is still tainted by the driver being present (installed, not necessarily loaded). Who knows what files and registry entries it dumped where, which system files might've been replaced, etc.

You've already whittled it down to a very reasonable number of variables. I strongly recommend you start over with a clean install, then introduce one(!) change at a time and verify. And keep the changes as small as possible, i.e. if possible remove the USB card and only then install NUSB, test, reinsert card, test, plug in a device, test, ...

elszgensa wrote on 2025-11-15, 19:22:

You could change your shell from explorer to something else, like good old progman.exe, or something third party like bb4win. You could even boot straight into Olly and go from there... Anyways, the idea is to hopefully get the system up without starting explorer.exe at all. At this point you could, for example, open and prepare Filemon and Olly and leisurely launch a debug-attached explorer instead of having to time anything. Or if you still get the message when the new shell starts, at least you know it's not specifically explorer's fault.

I'm... not sure what those are. Or how I'd go about doing any of that. ^^; That's all new territory for me.

Maybe not a device or the controller, but your system is still tainted by the driver being present (installed, not necessarily loaded). Who knows what files and registry entries it dumped where, which system files might've been replaced, etc.

You've already whittled it down to a very reasonable number of variables. I strongly recommend you start over with a clean install, then introduce one(!) change at a time and verify. And keep the changes as small as possible, i.e. if possible remove the USB card and only then install NUSB, test, reinsert card, test, plug in a device, test, ...

Okay. I guess that's something I can do over the rest of the weekend. Though I don't have a USB card. I have the ones at the back of the PC via the I/O ports and the device I've been using is like a USB extension. A small box with some USB ports. As mentioned, I'm sure that error came up after I'd finished reformatting last time. I'm sure it popped up after restarting the PC and booting to the desktop. But I'll try to be as methodical as I can with each thing I do. See if, when, and where it pops up again.

DustyShinigami wrote on 2025-11-15, 20:47:

I'm... not sure what those are. Or how I'd go about doing any of that.

You know your taskbar and wallpaper-with-icons-on? That's the "shell", and the one you're used to gets drawn by an instance of explorer.exe that gets started when your user account logs in. But you can replace that process with something else: 10 98. Then, Windows does NOT start explorer (which in turn loads all kinds of extensions) but whichever thing you told it to, which hopefully won't load whatever is throwing that error, and is then free to render its own interpretation of what a desktop should look like. "progman" is the old Windows 3 Program Manager interface, bb4win is derived from a Linux-y group of window managers (blackbox/openbox), but you could put basically anything you want there. (Just keep in mind that you likely eventually want a way to revert the change, so if you boot into something not meant as a shell, like Steam or Minesweeper, you might have to get creative to launch regedit or notepad, since, remember, no task bar so no start menu.)

edit: one thing to note, if you replace the shell and then proceed to launch explorers from it (e.g. by opening a folder with the default application), the first instance may think it's supposed to run as a shell. and now you have two programs trying to shell you at the same time, which will look weird... but just for troubleshooting it should be acceptable. good, even, since that way it should go through all the same motions as it did before, and not behave any differently.

elszgensa wrote on 2025-11-15, 21:17:

DustyShinigami wrote on 2025-11-15, 20:47:

I'm... not sure what those are. Or how I'd go about doing any of that.

You know your taskbar and wallpaper-with-icons-on? That's the "shell", and the one you're used to gets drawn by an instance of explorer.exe that gets started when your user account logs in. But you can replace that process with something else: 10 98. Then, Windows does NOT start explorer (which in turn loads all kinds of extensions) but whichever thing you told it to, which hopefully won't load whatever is throwing that error, and is then free to render its own interpretation of what a desktop should look like. "progman" is the old Windows 3 Program Manager interface, bb4win is derived from a Linux-y group of window managers (blackbox/openbox), but you could put basically anything you want there. (Just keep in mind that you likely eventually want a way to revert the change, so if you boot into something not meant as a shell, like Steam or Minesweeper, you might have to get creative to launch regedit or notepad, since, remember, no task bar so no start menu.)

I see. That does make sense. Although it sounds like a potentially complicated and deep rabbit-hole to go down. ^^

I'll stick to a clean reformat first and test things individually; sounds like a safer option at the moment. 😀