See what your effective PATH statement is, then verify %foo-program-notfound is in it?

wierd_w wrote on 2025-10-27, 18:33:

See what your effective PATH statement is, then verify %foo-program-notfound is in it?

I'm not sure I follow.

At a dos prompt:

SET

(No variable)

Will puke out every envirionment variable, including PATH.

Verify that 'the file that is not found' exists within the reported path list.

If it does not, then add it to the path variable in autoexec.bat

Something like

SET PATH=%PATH%;[your missing path here]

* Windows adds stuff to the path variable when it starts, such that some commonly used programs can just be run without a qualified path being provided. It uses many facilities to do this, which is why I explicitly said 'effective path statement'.

SET from the windows commandprompt will list this effective path.

Windows appends all its stuff to the end of the DOS path variable set by autoexec.bat, so setting a path there will work, especially since you are saying the programs/libraries not being found are being reported during windows startup (before it prods the user envirionment).

** Even if you might not be aware of it, the PATH variable gets populated by msdos.sys on win9x. This is why the proper way to add a path uses the %PATH% token in autoexec.bat.

wierd_w wrote on 2025-10-27, 18:43:

At a dos prompt: […]
Show full quote

At a dos prompt:

SET

(No variable)

Will puke out every envirionment variable, including PATH.

Verify that 'the file that is not found' exists within the reported path list.

If it does not, then add it to the path variable in autoexec.bat

Something like

SET PATH=%PATH%;[your missing path here]

* Windows adds stuff to the path variable when it starts, such that some commonly used programs can just be run without a qualified path being provided. It uses many facilities to do this, which is why I explicitly said 'effective path statement'.

SET from the windows commandprompt will list this effective path.

Windows appends all its stuff to the end of the DOS path variable set by autoexec.bat, so setting a path there will work, especially since you are saying the programs/libraries not being found are being reported during windows startup (before it prods the user envirionment).

** Even if you might not be aware of it, the PATH variable gets populated by msdos.sys on win9x. This is why the proper way to add a path uses the %PATH% token in autoexec.bat.

Huh. Interesting. Though I’m still somewhat confused. 😅 But putting SET gives me this:

I should point out that when it throws that error/warning, it doesn’t do it every time. There are plenty of times where it boots perfectly fine with no issues. It just has random moments where it does.

But typing in DIR for Windows/Command doesn’t list anything called ‘xit’

EDIT: Okay, coming out of DOS back into Windows, it threw the error at me again. 😅

EDIT 2: Just tried adding the path to autoexec.bat and rebooted, but it still gave me the error. 😕

I suspect this ‘xit’ has something to do with my sound card/drivers…? I’ve noticed it caused the Windows startup sound to cut off and now no audio/sounds play.

EDIT: Yeah. Switching to my Yamaha ISA sound card and rebooting doesn’t give me the error.

There is a program (Dependency Walker / Dependencies) that reads an executable and list every DLL needed. It also marks every DLL not found/not available (i.e.: not installed or outside the program path).

But keep in mind that some system DLLs (maybe "managed" by the OS) may be listed in a somewhat confusing state...

maybe check the registry to see what it's trying to run at startup time. software/microsoft/windows/currentversion/run (or something like that)

Download FileMon 7.04, open the filter dialog.

You have two options: You can either enter the file name (xit) into the filter, FileMon will then tell you which program is trying to access that file at any moment. One problem is that if you don't know the file path, only the name, you have to work with wildcards (*xit*) and you'll probably get tons of unrelated results.

Or, enter a program name that you suspect, then see which files it's trying to access at launch. FileMon will then log the program activity and show you everything it's trying to access.

bakemono wrote on Yesterday, 08:43:

maybe check the registry to see what it's trying to run at startup time. software/microsoft/windows/currentversion/run (or something like that)

Yep, that's a great idea. If you're getting the error at boot, it's most likely a program that's being run from the Autorun key. For example, if "C:\creative\mixer.exe" (just an example) is in that list, you would add "c:\creative\mixer.exe" to the FileMon filter, then launch mixer.exe manually and see what happens.

And related to that, try disabling the HPT controller in the BIOS and hook up your drives to the first controller. There are so many reports online on that controller being buggy and corrupting other devices on the PCI bus. If you rule that out first, it might save you a lot of time troubleshooting.

Zup wrote on Yesterday, 05:44:

There is a program (Dependency Walker / Dependencies) that reads an executable and list every DLL needed. It also marks every DLL not found/not available (i.e.: not installed or outside the program path).

But keep in mind that some system DLLs (maybe "managed" by the OS) may be listed in a somewhat confusing state...

Thanks for the suggestion. I'll give it a try and see. I suspect I may get confused with it though. ^^;

bakemono wrote on Yesterday, 08:43:

maybe check the registry to see what it's trying to run at startup time. software/microsoft/windows/currentversion/run (or something like that)

Okay, thanks. I suspect that will list what you would also find via msconfig? Under the Startup tab? I did peruse that last night and unticked/ticked a few things. There were some Creative SB options in there I re-toggled and so far that warning hasn't come up. Though it would be nice to pinpoint what/where it's coming from exactly.

asdf53 wrote on Yesterday, 09:08:

Download FileMon 7.04, open the filter dialog. […]
Show full quote

Download FileMon 7.04, open the filter dialog.

You have two options: You can either enter the file name (xit) into the filter, FileMon will then tell you which program is trying to access that file at any moment. One problem is that if you don't know the file path, only the name, you have to work with wildcards (*xit*) and you'll probably get tons of unrelated results.

Or, enter a program name that you suspect, then see which files it's trying to access at launch. FileMon will then log the program activity and show you everything it's trying to access.

bakemono wrote on Yesterday, 08:43:

maybe check the registry to see what it's trying to run at startup time. software/microsoft/windows/currentversion/run (or something like that)

Yep, that's a great idea. If you're getting the error at boot, it's most likely a program that's being run from the Autorun key. For example, if "C:\creative\mixer.exe" (just an example) is in that list, you would add "c:\creative\mixer.exe" to the FileMon filter, then launch mixer.exe manually and see what happens.

And related to that, try disabling the HPT controller in the BIOS and hook up your drives to the first controller. There are so many reports online on that controller being buggy and corrupting other devices on the PCI bus. If you rule that out first, it might save you a lot of time troubleshooting.

Awesome. Thank you. Again. ^^ Did you suggest FileMon to me before? Not sure I downloaded it and it's currently waiting to be transferred and used. Either way, that sounds promising. 😀

But yes, I'll give all of these methods a try and report back.

Re: PATH variable

The path variable works like this:

When a command is entered at the prompt, the interpreter tries to fullfill it, checking things in this order.

1) Is the command in my builtin list?
(Things like dir, copy, del, etc)

2) is this a .com, .exe, or .bat in the local directory context? (Searched in that order)

3) if it's not either of those things, start walking the PATH variable. Is the entered command a .com, .exe, or .bat found in any of the paths in the variable's list?

If no to all of these, 'invalid command', or 'file not found'.

Windows keeps a great many ways to keep track of where things are, using the path, as well as registry entries, and .inf file declaration entries.

If the registry does not have a path for a library or program defined, and there is no .inf involved that might tell windows where to look, it will also fall-back on checking the path variable.

As I said in my last post, the path gets populated in this manner:

In msdos.sys, there is a declaration which sets this initially, along with the drive letter windows is installed on. This initially populates PATH with [drive:\]windows;[drive:\]windows\command

This is why you can run things like scandisk without any trouble, and why just putting 'win' at the prompt anywhere can start windows, even if you tell windows to skip autoexec.bat and config.sys

Autoexec.bat will also get a declaration for PATH by default after installing windows, but it basically just contains a less intelligently applied version of this basic path.

It's mainly there for dos compatibility, as many dos programs want their folders in the path statement, so that they can better handle having been installed in a user defined location. They can be run, and find all their libraries easily this way.

And lastly, when windows starts, it appends a path statement to the end, based on a string value stored in the registry. Like dos programs, many win32 console programs want to have entries in this variable for the same reasons, and windows supplies this facility for these win32 console programs, without cluttering the statement in autoexec.bat. This is why the 'effective path' from a prompt within windows can be quite different than the one at the actual dos prompt when windows is not running.

Why all this might matter:

In the early stages of starting (like when it is setting up the vmm, loading vxd files, and getting the windows kernel ready) the facilities for loading and appending this windows specific path have not been activated yet. If a vxd, for instance, needs some helper program to run (like your mysterious 'xit'), it needs to be inside the path statement to be found. This is generally why such helper programs get copied to %windir%/system32 or %windir%/system. That's the local context that win.com switches to after it gets run. If it's in there, it will be found immediately, at condition 2 cited earlier.

If it cant find it there, it will check the path.

LATER in the startup process, when user32 and pals get started, and the user space and shell get started, then things in the RUN registry key fire.

By this time, the windows paths are appended already.

What I asked you to check was:

Can you find any program or dll named 'xit'?

(For instance, looking using dir from dos:)

C:
cd \
dir xit.* /s

Then looking for output on where it's found.

If such a thing is found (xit.com, xit.exe, xit.bat, xit.vxd, xit.dll), note the path it resides at.

Is that path inside the path variable?

If it is not, ADD that path to the variable.

Others have made good suggestions as well, such as dependency walker.

Depends.exe loads some program you want to check, and then keeps track of every library or program it calls to do stuff (and all the programs and libraries THOSE call to do stuff), so that you can quickly find which dependency is not being met.

This cant be run at the early stages of windows being loaded though. 😁 (the user space is not set up and loaded yet!)

I see. It'll take a few re-reads to process it, but I get the general gist, I think. At the very least, I'm learning something new all the time when I post to these forums. 😀 I can try running the dir command in DOS, now that I've seemingly enabled the tool on startup, which appears to have resolved the issue/error, and see if it'll find it.

On another note: I take it if I were to customise my boot menu, so I have appropriate names/options - Windows 98 SE, MS-DOS etc - I would need to have some commands in autoexec.bat or config.sys, but there would need to be something stored in the msdos.sys to call them first? I'm a bit confused how, from what I've read online, the needed commands for custom menus are in autoexec/config. If those files aren't fired until after you select Command Prompt from the default menu, then the menu will stay as it is with the default names? Thanks.

Msdos.sys is called by the boot sector.

You can override what it sets for you later with autoexec.bat.

Such as setting a new WINDIR and pals.

I bet this is some script or similar that is actually trying to execute "exit" and the first character is being eaten due to some encoding issue.

Could be, yeah.

But helper programs are notorious for having unscruitable names as well.

wierd_w wrote on Yesterday, 12:39:

Re: PATH variable […]
Show full quote

Re: PATH variable

The path variable works like this:

When a command is entered at the prompt, the interpreter tries to fullfill it, checking things in this order.

1) Is the command in my builtin list?
(Things like dir, copy, del, etc)

2) is this a .com, .exe, or .bat in the local directory context? (Searched in that order)

3) if it's not either of those things, start walking the PATH variable. Is the entered command a .com, .exe, or .bat found in any of the paths in the variable's list?

If no to all of these, 'invalid command', or 'file not found'.

Windows keeps a great many ways to keep track of where things are, using the path, as well as registry entries, and .inf file declaration entries.

If the registry does not have a path for a library or program defined, and there is no .inf involved that might tell windows where to look, it will also fall-back on checking the path variable.

As I said in my last post, the path gets populated in this manner:

In msdos.sys, there is a declaration which sets this initially, along with the drive letter windows is installed on. This initially populates PATH with [drive:\]windows;[drive:\]windows\command

This is why you can run things like scandisk without any trouble, and why just putting 'win' at the prompt anywhere can start windows, even if you tell windows to skip autoexec.bat and config.sys

Autoexec.bat will also get a declaration for PATH by default after installing windows, but it basically just contains a less intelligently applied version of this basic path.

It's mainly there for dos compatibility, as many dos programs want their folders in the path statement, so that they can better handle having been installed in a user defined location. They can be run, and find all their libraries easily this way.

And lastly, when windows starts, it appends a path statement to the end, based on a string value stored in the registry. Like dos programs, many win32 console programs want to have entries in this variable for the same reasons, and windows supplies this facility for these win32 console programs, without cluttering the statement in autoexec.bat. This is why the 'effective path' from a prompt within windows can be quite different than the one at the actual dos prompt when windows is not running.

Why all this might matter:

In the early stages of starting (like when it is setting up the vmm, loading vxd files, and getting the windows kernel ready) the facilities for loading and appending this windows specific path have not been activated yet. If a vxd, for instance, needs some helper program to run (like your mysterious 'xit'), it needs to be inside the path statement to be found. This is generally why such helper programs get copied to %windir%/system32 or %windir%/system. That's the local context that win.com switches to after it gets run. If it's in there, it will be found immediately, at condition 2 cited earlier.

If it cant find it there, it will check the path.

LATER in the startup process, when user32 and pals get started, and the user space and shell get started, then things in the RUN registry key fire.

By this time, the windows paths are appended already.

What I asked you to check was:

Can you find any program or dll named 'xit'?

(For instance, looking using dir from dos:)

C:
cd \
dir xit.* /s

Then looking for output on where it's found.

If such a thing is found (xit.com, xit.exe, xit.bat, xit.vxd, xit.dll), note the path it resides at.

Is that path inside the path variable?

If it is not, ADD that path to the variable.

Just tried…

C:
cd \
dir xit.* /s

…in DOS, but it says file not found.

Then no such file exists *anywhere* on the C drive. 😁

Time to look more closely at your configuration, and maybe that soundcard driver's package.