View Full Version : Bug in my computer

December 11th, 2006, 18:11
This is not completely RCE related, That is why it is in the off topic forum.

My computer, WinXP SP2 has an annoying problem, which I hope someone here has experimented and knows a solution.

Let us say I have a program called myprog.exe, a small self contained module.

I try to run the program by double clicking on it, and windows shows a message box saying: Windows cannot find 'C:\. . . \desktop\myprog.exe'. Make sure you typed the name correctly then try again. To search for a file click the Start Button, then click Search.

Well the file is right there. If I try to start the file using the cmd window I get a 'file not found' message, despite the file being visible by a dir command.

I have gone through the file permissions, installed down to C:\ root, run as an admin. . .

To no avail. If I copy the file to another computer, it starts in flying colors.

It happens with a few of the executables, not all of them.


It appears that these files are not visible to the windows loader. Anyone knows what the problem might be / What else can I check/and a solution?

Thank you

December 11th, 2006, 18:54
Couple of ideas, did you update your AV?? sometimes you will get a wormy that will affect the loader etc...(ahem....). how about a defrag.

December 11th, 2006, 19:14
Yeah. I thought about an infectious bug. The Anti virus and the anti pests come clean. I saw this as a symptom of infection when I searched fro the error message, but so far it does not seem to pan out as an infection.

December 11th, 2006, 19:45
have you tried to move it to root and rename it to an old 8.3 name?
you said 'few files', are you sure no rootkit-like technology is stealthing them from the loader?
ooh... wait I know! do you have/had more than one admin account there?
Check its CSLID or whatever it's spelled that damn thing.
It usually makes me madden in windows, as there is no clear way to set file's owenrship.
99% it is related to this. No matter if you have admin account...

December 11th, 2006, 21:34
jus a thought, go to the admin tools and select services and maybe a service has to be started manually.

December 12th, 2006, 00:24
[Originally Posted by UrgeOverKill;63066]jus a thought, go to the admin tools and select services and maybe a service has to be started manually.
You don't really need much in the way of services to start programs...

Perhaps the exe file association key in the registry has been corrupted somehow. Make sure that the Open action has quotes around the %1.

December 12th, 2006, 01:57
You need to clear the file cache that windows builds...

Have Phun

December 12th, 2006, 13:09
Assuming you have the Debugger Tools for Windows, try this:

gflags /i "c:\temp\screwy prog.exe" +sls

That will enable the "Show Loader Snaps" flag for your program. Then start Windbg and load the application. The LDR: output might give you a better idea of what's going wrong with the loader (if it even is the loader). Clear the flags when you're done with:

gflags /i <application> -all

A few other things to try:

It could be a filesystem glitch. Try running chkdsk from the Recovery Console, or a live CD.
Try loading the app from Olly.
Try loading it from another process. Perhaps try both CreateProcessA and WinExec.
Make a shortcut to it and run the shortcut.
Launch it from a scheduled task.

That's all I can think of to gather more diagnostic info.

December 12th, 2006, 15:37
me stiil thinks it is something to do w/the AV settings............ which one are you using?

December 12th, 2006, 17:07
Doing an inventory of the "impaired" files I found a pattern: Old, 16 bit files are the ones that refuse to load. 32 bit applications load perfectly.
I realized that when I was trying to load HIEW.

The old hiew.exe (16 bit) refuses to load. I am positive It used to load before

hiew32.exe loads just fine. So it seems that the problem/bug is somewhat related with the 16 bit virtual machine loader.

I am going through an inventory of all the problem files and see if this pattern holds. So far it is true with 9 out of nine.

I have to deal with a lot of old/technical/legacy 16 bit software at work.

December 12th, 2006, 17:25
Just to be safe, make sure that HKEY_CLASSES_ROOT\.exe points to exefile, and HKEY_CLASSES_ROOT\exefile\shell\open\command is set to "%1" %*.

December 13th, 2006, 04:38
well if just 16 bit programs dont run try start->run -> command.com

if it didnt run find the config.nt_ and autoexec.nt_ in the cd or 1386 directory and use exapnd to expand them and restore them to %system%\system32

also i remember something about conagent.exe or ist it CONIN and redir.exe (some vintage win95 or possibly win3.1 crap that still needs to cling in the newer oses for some dumb compatibilty (possibly for running some ancient wordperfect bs by trillion dollor earning lawyers these both arent probably installed by default or probably do not even exist in cd but getting them and putting them in path makes things work) but googling now i cant locate anything pertinent atm if i find some thing ill post back

in the mean time also take a look at c:\window\system (just system not system32) thats where all these 16 bitties sleep (some trivia the setup.exe that runs the winxp setup still has to rely on them to some exetent try taking a look on setup.inf you will see xp is trying to install win 3.1

you will even find one mmtask.tsk which is a NE executable for some multimedia compatiblity a scheduled task

good luck
almost all the problems like
no resource
ntvdm not able to find something
kind of errors all start from here and they mostly happen with preinstalled custom tailored norton ghosted recovery disked os installs (the service guy takes billions of dollors takes all your cd that came with the laptop
and does
cd f:\
ghostpe image.gho
and returns back your laptop to you laughing all the way to bank


by the way i found that mskb but i think i misremebered cant find message with not suitable message so my ramblings above are probably useless
here is the mskb that i was talking about

you say you got it to c:\ so that probably also eliminates the path with spaces

(if you try masm32 qeditor-->project-->bulidall on an asm file which resided in a directory with spaces in the path it will err with the same message cant find file
but if it is still saying cant find in c:\ then one last guess would be to see if there is any associated pif files and see if that pif file has some hardcoded path which has spaces in it
which may be the culprit i dont know just a guess normally if a pif existed it has precedence over double click i think im not sure

December 13th, 2006, 15:57
God dammit I love the people and knowledge on this board...

December 13th, 2006, 21:53
Had a similar problem a couple of years ago. Different error message but I couldn't run any 16 bit apps without a lot of error messages and clicking "ignore", if they ran at all. I solved it by doing a repair installation of the Xp system. I read a lot about the 16 bit ms-dos subsystem, searched through the registry quite a bit and finally lost patience and opted for the brute force approach a repair installation--a real pain.

This is what MS support has to say about it:


Might help. If I had googled them then, I might have spared myself the pain of the repair installation.

December 15th, 2006, 16:18
I have written this answer 7 times over the last four days, and always something bad happens to my computer or I get distracted, or my computer crashes. . .

Sorry for not getting back to you guys before. I am very thankful for your suggestions and your guidance. I have systematically tried every one of them, to no avail. I have installed the non-running aps in Virtual machines , and they do OK.

I think the issue is an unfortunate registry setup or a problem with file ownership, but I grew tired of looking for answers. I am going to take ElMago Approach and reinstall windows. Is about time in any case, to clean house.

Thank you