[Webinar] Streamline your web hosting managementRegister Today

x
• Status: Solved
• Priority: Medium
• Security: Public
• Views: 493

# Folder Does Not Exist - Explorer Error

I seem to have recently developed a problem with the Windows 98 SE explorer and the way that the Run command on the start-menu executes paths.

For example, if I type in "C:\Program Files" without quotes then I get the following errors...

The folder 'C:\"C:\Program Files"' does not exist
The folder 'C:\"C:\Program Files"' does not exist

Yep, the error occurs twice.

Also this same problem occurs if using the ShellExecute API set to "open" a folder location.

I have noticed that by adding explorer to the front of the path to open that everything works fine as before. What has changed, and what can I do to correct this problem?

Currently all applications that open paths now generate these two errors through Windows, and it's really starting to get annoying, and I don't of course want to reinstall the whole OS for the sake of one issue.

Any suggestions?
0
peterchamberlin
• 10
• 6
• 3
• +3
1 Solution

Commented:
You may want to check the path staement in the autoexec.bat
you may also want to boot to dos, and from the prompt type
scanreg /fix
note the space between scanreg and /fix
also go to start-->run and type sfc and let system file checker check for bad or missing files
0

retiredCommented:
And if the above doesn't work, another option to try is the command scanreg/restore when you've booted to DOS, and choose a date of the registry before this happened.  The fact that if you type explorer before a folder path, it works, but otherwise not, leads me to believe that somehow there has been a corruption in your registry which has destroyed the association of Explorer with either, or both, of the following: Folder, and File Folder.  (In Windows Explorer, click on Tools, then Folder Options. Then look at the File Types tab.)
0

Commented:
http://support.microsoft.com/support/kb/articles/q130/5/97.asp
You might find it usefull.
Good luck
Navid
0

Author Commented:
Thanks for the pointer to the M$KB article, although the error is similar I don't think it matches the situation I'm experiencing. As LeeTutor suggested I think that something may have gone wrong with registry assocations, although checking in File Types I see that folders are currently associated with explorer.exe in any case. The path in my autoexec.bat file is as it has always been, i.e. SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND The folder file type settings seem fine, however I see that file folder file type is opening with command.com. I don't know whether this is normal behaviour as I've never come across that entry in File Types before. There is no 'open' entry within the file types, so I presume that it's a system default to go to command.com. I will try the scanreg /fix option as well as SFC and see whether this resolves the problem. If not I'll let you know. Back shortly... 0 Author Commented: I'm back... I ran SFC first and went through everything and there were no missing critical system files, only a few files that I know have been uninstalled and SFC was warning me about. I updated the DB of files accordingly. Next I shutdown and rebooted to command line and ran scanreg /fix, which promptly checked and rebuilt the user.dat file, and then took an age to rebuild the system.dat file (initial 2 checks were pretty quick, third took nearly 10 mins !). Rebooted and I still find that problem is there. I tried opening "C:\" and got the 2x errors as stated previously. Any tips on what to do next? 0 retiredCommented: Did you try my idea of scanreg /restore to a date before the problem came into being (if that wasn't too long ago?) And, on my Windows 98SE system, both "Folder" and "File Folder" open with Explorer, according to the File Types tab of Folder Options. 0 Commented: Does'nt hurt to run scandisk. Never know when a FAT going to get messed up. It also sounds like you have a bloated registry. Maybe it needs a little house cleaning. But such things are very scary. Be afraid, be very afraid. Always backup the registry to another folder. Say reg_backup or something like that. Windows only keeps 5 days of backup. If your registry breaks beyond that, you're out of luck. 0 Commented: I had this crazy situation after I had problems installing Office 2000, perhaps it was one of the service patches. Did you? In fact, what all recently changed? 0 Commented: Did you install Windows in the default directory? 0 Commented: I'd do this: start-find-files folders-*.* in the files and then this in the containing text field to see what all is calling for this, or whatever the actual error message is: 'C:\"C:\Program Files"' does not exist Alternatively this: normal shutdown, leave off 2-3 minutes, reboot holding CTRL select MS dos prompt only. Assuming you installed windows in the default directly, at the prompt: cd c:\windows\command then scanreg/fix See if repairing the registry helps. Asta 0 Author Commented: I would have tried the registry restore, however the problem occurred just a little over 6 days ago and I thought that it may have been just an odd Windows thing so rebooted and promptly forgot about it until I noticed it again a day or so ago then started to try to do something about it. Interesting how you have Explorer opening the File Folder option (LeeTutor). Could you perhaps isolate the registry entries associated with the File Folder, extract them to a .reg file and send them to my email address (peter@chamberlin1.freeserve.co.uk) so that I may compare with my system. I could find the .Folder entry in HKCR however couldn't immediately see .File Folder so will do a registry scan shortly for that. I'm on a FAT32 only sytsem, and did a scandisk through Windows when I realised about the problem. Only reported faults were some of the folder information many directory levels down, but that was due to DOS compatibility issues. I have Office 2000 with latest service pack installed, and haven't made any changes to its installation for nearly 6 months now. Windows is installed in the default directory of C:\Windows, and I have the Win98 CABs in a hidden folder in C:\W98FLAT. I did once have to reinstall 98, which I do by process of an overlay installation - but that didn't cause any problems at all and was well over a year ago. Have performed a regscan /fix as previously mentioned, with no improvement to the situation. Astaec, did you manage to resolve the problem? Let me know... 0 Author Commented: FYI I have posted a copy of the exports from my registry of the Folder and Directory keys under HKCR (The Directory one is what is called 'File Folder' under the File Types dialog) to the following URL... http://www.geocities.com/peterchamberlin/regexports.zip Looking at the Directory key I see that the first program under there is a shell patch added ages ago that allows me to go to DOS prompt by right clicking on a directory. The next one is the standard Find Files entry. This is probably the reason why I have Command.COM displayed on File Types (As DOS opens with that) instead of Explorer.EXE (As Find Files opens with that). Still, the exports may show up something else. I'm not sure though that they are at the root of the problem now though, as the folder entry is just for Windows folders and the file folder entry is for the menu additions that appear to the right click menu you get with folders. The problem I'm experiencing seems to be purely occurring when a path name is passed to explorer to open, or rather a path name isn't being passed to explorer to open - unlike it used to be. 0 retiredCommented: Hello, peterchamberlin, I FINALLY was able to log on to Experts-Exchange tonight, after the site being down all day. I downloaded your Regedit files. I believe Experts Exchange policies forbid me to communicate with you via email to send you an answer. But I exported my Registry keys for Directory and Folder, opened them in Notepad, and here is what they are. Directory folder first: REGEDIT4 [HKEY_CLASSES_ROOT\Directory] @="File Folder" "EditFlags"=hex:d2,01,00,00 "AlwaysShowExt"="" [HKEY_CLASSES_ROOT\Directory\shell] @="" [HKEY_CLASSES_ROOT\Directory\shell\find] @="" [HKEY_CLASSES_ROOT\Directory\shell\find\ddeexec] "NoActivateHandler"="" @="[FindFolder(\"%l\", %I)]" [HKEY_CLASSES_ROOT\Directory\shell\find\ddeexec\application] @="Folders" [HKEY_CLASSES_ROOT\Directory\shell\find\ddeexec\topic] @="AppProperties" [HKEY_CLASSES_ROOT\Directory\shell\find\command] @="C:\\WINDOWS\\Explorer.exe" [HKEY_CLASSES_ROOT\Directory\shell\NewFolder16 by _RsoFT_] @="&New folders here" [HKEY_CLASSES_ROOT\Directory\shell\NewFolder16 by _RsoFT_\command] @="C:\\WINDOWS\\folder.pif" [HKEY_CLASSES_ROOT\Directory\shell\DiskInfoByPplus] @="Disk &Information" [HKEY_CLASSES_ROOT\Directory\shell\DiskInfoByPplus\command] @="C:\\WINDOWS\\SYSTEM\\Shellext\\ppshlext.exe \"%1\" /dinfo" [HKEY_CLASSES_ROOT\Directory\shell\TCMD32] @="&Take Command Prompt here" [HKEY_CLASSES_ROOT\Directory\shell\TCMD32\command] @="C:\\PROGRA~1\\TAKECO~1\\TCMD32.EXE /k *cdd %1" [HKEY_CLASSES_ROOT\Directory\shell\ChangeIcon] @="Change &icon" [HKEY_CLASSES_ROOT\Directory\shell\ChangeIcon\command] @="\"D:\\WINADDONS\\CHANGEICON\\CHANGEICON.EXE\" %1" [HKEY_CLASSES_ROOT\Directory\DefaultIcon] @="C:\\WINDOWS\\SYSTEM\\shell32.dll,3" [HKEY_CLASSES_ROOT\Directory\shellex] [HKEY_CLASSES_ROOT\Directory\shellex\CopyHookHandlers] [HKEY_CLASSES_ROOT\Directory\shellex\CopyHookHandlers\FileSystem] @="{217FC9C0-3AEA-1069-A2DB-08002B30309D}" [HKEY_CLASSES_ROOT\Directory\shellex\CopyHookHandlers\CDF] @="{67EA19A0-CCEF-11d0-8024-00C04FD75D13}" [HKEY_CLASSES_ROOT\Directory\shellex\CopyHookHandlers\MyDocuments] @="{450D8FBA-AD25-11D0-98A8-0800361B1103}" [HKEY_CLASSES_ROOT\Directory\shellex\ExtShellFolderViews] [HKEY_CLASSES_ROOT\Directory\shellex\ExtShellFolderViews\{5984FFE0-28D4-11CF-AE66-08002B2E1262}] "PersistMoniker"=hex(2):66,69,6c,65,3a,2f,2f,43,3a,5c,57,49,4e,44,4f,57,53,5c,\ 77,65,62,5c,66,6f,6c,64,65,72,2e,68,74,74,00 [HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers] "ICQMenu"="" [HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers\WinZip] @="{E0D79300-84BE-11CE-9641-444553540000}" [HKEY_CLASSES_ROOT\Directory\shellex\DragDropHandlers] [HKEY_CLASSES_ROOT\Directory\shellex\DragDropHandlers\WinZip] @="{E0D79301-84BE-11CE-9641-444553540000}" [HKEY_CLASSES_ROOT\Directory\shellex\PropertySheetHandlers] [HKEY_CLASSES_ROOT\Directory\shellex\PropertySheetHandlers\InfoTipX] @="{1B4DA176-F47D-11D1-B8BE-00A0C90358E7}" [HKEY_CLASSES_ROOT\Directory\shellex\{00021500-0000-0000-C000-000000000046}] @="{49329585-5587-11D1-9635-00A0C90358E7}" [HKEY_CLASSES_ROOT\Directory\Background] [HKEY_CLASSES_ROOT\Directory\Background\shellex] [HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers] [HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\New] @="{D969A300-E7FF-11d0-A93B-00A0C90F2719}" You can ignore the keys for NewFolder16, DiskInfobyPPlus, TCMD32, and ChangeIcon, for those are freeware Windows utilities I have installed on my computer, but probably are not present on yours. I believe there are other keys you can ignore, too. I don't have a working printer right now, which would greatly facilitate my comparing your keys with mine, but I will try to do it visually on my Display and get back to you if I find a significant datum. 0 retiredCommented: Here's my Folder reg export: REGEDIT4 [HKEY_CLASSES_ROOT\Folder] @="Folder" "EditFlags"=hex:d2,01,00,00 [HKEY_CLASSES_ROOT\Folder\DefaultIcon] @="C:\\WINDOWS\\SYSTEM\\shell32.dll,3" [HKEY_CLASSES_ROOT\Folder\shell] @="" [HKEY_CLASSES_ROOT\Folder\shell\open] @="" [HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec] "NoActivateHandler"="" @="[ViewFolder(\"%l\", %I, %S)]" [HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec\application] @="Folders" [HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec\topic] @="AppProperties" [HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec\ifexec] @="[]" [HKEY_CLASSES_ROOT\Folder\shell\open\command] @="C:\\WINDOWS\\Explorer.exe /idlist,%I,%L" [HKEY_CLASSES_ROOT\Folder\shell\explore] @="" [HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec] "NoActivateHandler"="" @="[ExploreFolder(\"%l\", %I, %S)]" [HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec\application] @="Folders" [HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec\topic] @="AppProperties" [HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec\ifexec] @="[]" [HKEY_CLASSES_ROOT\Folder\shell\explore\command] @="C:\\WINDOWS\\Explorer.exe /e,/idlist,%I,%L" [HKEY_CLASSES_ROOT\Folder\shell\treesize] @="TreeSi&ze" "EditFlags"=hex:01,00,00,00 [HKEY_CLASSES_ROOT\Folder\shell\treesize\command] @="C:\\WINDOWS\\Treesize.exe /idlist %I \"%1\" " [HKEY_CLASSES_ROOT\Folder\shell\Print with DirPrn ...] [HKEY_CLASSES_ROOT\Folder\shell\Print with DirPrn ...\command] @="\"C:\\PROGRAM FILES\\PWDIRPRN\\DIRPRN\" \"%1\"" [HKEY_CLASSES_ROOT\Folder\shellex] [HKEY_CLASSES_ROOT\Folder\shellex\ExtShellFolderViews] [HKEY_CLASSES_ROOT\Folder\shellex\ExtShellFolderViews\{5984FFE0-28D4-11CF-AE66-08002B2E1262}] "PersistMoniker"="file://C:\\WINDOWS\\web\\default.htt" [HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers] [HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\WinZip] @="{E0D79300-84BE-11CE-9641-444553540000}" [HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\PropertiesPlus] @="{0b95b7e0-c8b9-11cf-8f59-444553540000}" [HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\CA_AntiVirus] @="{1CE2AA40-1317-11D3-9922-00104B0AD431}" [HKEY_CLASSES_ROOT\Folder\shellex\DragDropHandlers] [HKEY_CLASSES_ROOT\Folder\shellex\DragDropHandlers\WinZip] @="{E0D79301-84BE-11CE-9641-444553540000}" 0 retiredCommented: I don't know whether it is significant or not, but here is a difference I found between your keys and mine: mine: [HKEY_CLASSES_ROOT\Directory\shell\find\command] @="C:\\WINDOWS\\Explorer.exe" yours: [HKEY_CLASSES_ROOT\Directory\shell\find\command] @="Explorer.exe" 0 Author Commented: LeeTutor, I don't think the difference you pointer out should be a major problem as I have C:\Windows defined within the PATH variable and so it should still kick off on Explorer.exe. And indeed the find command off the directory popup menu does work. I will try changing it to see whether it affects any thing, but I'm doubtful. HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec] "NoActivateHandler"="" @="[ViewFolder(\"%l\", %I, %S)]" The above key looks to be of interest. What I will do is make a backup of my reg, and those keys, then replace them with your data and see what happens - perhaps rebooting between if necessary. Will let you know. And yes, I know about EE. I thought they had removed my account, as I couldn't login, and I couldn't recreate the account. This also after I had just cleared out Internet cache to free up a little space (cookies too) and so was a little confused. I managed to get back in a little later though, evidently :) 0 Author Commented: Oh wow !!! It's working again :) I just did that reg merge and it's all operational, and so nice :) Thank you LeeTutor :) Smiley faces all around ! I won't stop here of course, I'll go identify the differences between registry keys to isolate the key of difference and let you know what was causing the problem so that other users can reference this in the future. I wonder how come that particular part of the registry got messde up in the first place. Perhaps an uninstall that went wrong? (not one of mine I hope lol) Will investigate the reg keys and get back to you... 0 Author Commented: Also a good idea to find the changed keys so that I can manually fix them to restore my original shell menus and so prevent further conflicts. I resorted to the print out method, after realising that the key exports are not in the same order, good ol' M$ recursive registry export. Still, the registry entries don't have to be sorted in storage, and that's where the exports come from. Would have been nice for M$to add their own sort routine to reg key exports. I did this myself actually in my self-written recursive registry export (after I realised that no easy way of doing REGEDIT4 export scripts was possible programmatically). 0 Author Commented: Okay, here's my summary of the differences between the incorrect registry entries on my system and the corrected one now. I've discounted obvious differences due to added/missing context menus... FOLDER ====== ** MISSING @="" ** [HKEY_CLASSES_ROOT\Folder\shell\explore] ** Triple \ Instead of Single \ ** [HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec] @="[ExploreFolder(\\\"%l\\\", %I, %S)]" ** MISSING @="" ** [HKEY_CLASSES_ROOT\Folder\shell\Open] ** Triple \ Instead of Single \ ** [HKEY_CLASSES_ROOT\Folder\shell\Open\ddeexec] @="[ViewFolder(\\\"%l\\\", %I, %S)]" ** Addition in Mine with Unknown Purpose ** [HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers\{969223c0-26aa-11d0-90ee-444553540000}] ** Addition in Corrected Version ** [HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec\ifexec] @=" []" ** Partial Addition of C:\Windows in Corrected ** [HKEY_CLASSES_ROOT\Folder\shell\open\command] @="C:\\WINDOWS\\Explorer.exe /idlist,%I,%L" FILE FOLDER (DIRECTORY) ======================= ** Triple \ Instead of Single \ ** [HKEY_CLASSES_ROOT\Directory\shell\find\ddeexec] @="[FindFolder(\\\"%l\\\", %I, %S)]" ** Addition in Correct Version ** [HKEY_CLASSES_ROOT\Directory\shellex\{00021500-0000-0000-C000-000000000046}] @="{49329585-5587-11D1-9635-00A0C90358E7}" The very last entry above seems to be to be perhaps one of the key elements, either that or those triple \ instead of single \'s. I will make progressive changes to my registry until I come across the entry that fixes the problem :) Back again shortly... 0 Author Commented: After adding each of those changes back to my original registry I have been unable to restore the functionality of running paths again :( This either means that I must have missed something when doing the comparison, or that the triple \s are important. With the triple \s, these appear in my registry export, however when I look at the data in regedit I see the information appear as in your registry export. Also when I run Regmon while doing the run file prompt I see that Explorer is accessing the paths and data as per your files, so presumably the triple \ is an oddity of my registry storage, but isn't making any actual difference. I have uploaded my regmon script (www.sysinternals.com) to the following URL so that you can see exactly what's happening in my registry at the time of folder access. The dde exec viewfolderpath key seems to be the all important one. You may wish to run regmon yourself over a similar activity, i.e. set up Run for C:\Program Files, then clear regmon (with filer for explorer.exe) then press enter and halt the capture of registry data. http://www.geocities.com/peterchamberlin/regmon.zip Next up I think I will get a program that does a comparison of registry entries automatically, and use that to isolate the differences better. If all else fails I know that I can just put back the edited regexports of yours and use those instead, but I would prefer to find the cause of this problem for future reference. 0 Author Commented: I found a nice program called RegBin which does a good comparison between .reg files, and allow an export in RTF format. I managed to isolate the fact that the reason for the problem was due to the data under the Folder key, and that it was a key being changed that was the problem (as I can apply both reg keys in sequence to toggle the error reported). I then generated a comparison between the files, isolated the list down to modified keys only, and the following report was generated... Added Keys: 16 Removed Keys: 13 Modified Keys: 6 Unchanged Keys: 33 Filter: Show Modified ________________________________________ Status: Modified Key Name: [HKEY_CLASSES_ROOT\FOLDER\SHELL\EXPLORE\COMMAND] Modified Key and Value: @="C:\\WINDOWS\\Explorer.exe /e,/idlist,%I,%L" Original Key and Value: @="Explorer.exe /e,/idlist,%I,%L" ________________________________________ Status: Modified Key Name: [HKEY_CLASSES_ROOT\FOLDER\SHELL\EXPLORE\DDEEXEC] Modified Key and Value: @="[ExploreFolder(\"%l\", %I, %S)]" Original Key and Value: @="[ExploreFolder(\\\"%l\\\", %I, %S)]" ________________________________________ Status: Modified Key Name: [HKEY_CLASSES_ROOT\FOLDER\SHELL\OPEN\COMMAND] Modified Key and Value: @="C:\\WINDOWS\\Explorer.exe /idlist,%I,%L" Original Key and Value: @="Explorer.exe /idlist,%I,%L" ________________________________________ Status: Modified Key Name: [HKEY_CLASSES_ROOT\FOLDER\SHELL\OPEN\DDEEXEC] Modified Key and Value: @="[ViewFolder(\"%l\", %I, %S)]" Original Key and Value: @="[ViewFolder(\\\"%l\\\", %I, %S)]" ________________________________________ As can be seen the obvious thing at the root of this problem are those triple back slashes (The C:\Windows prefix can be ignored as it's in my path variable). Now Windows 98se RegEdit.exe DOESN'T SHOW this backslashes in its normal display, however they do show up on the registry export ! How's that for data integrity :) Anyway, as you can see above these triple backslashes affect the ViewFolder explorer command and presumable corrupt the path. I also presume that the C:\ is appended by explorer as an attempt to recover the corrupted path. Ah, wait a second !! With the double \\ ADDED, when explorer looks at this path it will look like...a network address !! Remember the M$ KB article on this? I think that this is what's happening on my machine, except the problem lies with the backslash handling in the registry and explorer.exe thinks I'm trying to open a folder on a remote machine when in fact I'm not.

What's the guessing that if I make a reg path with just those triple backslashes removed then this problem will all go away? Well, here goes...

YAY !! It worked :) My registry fixing patch is as follows...

REGEDIT4

[HKEY_CLASSES_ROOT\Folder\shell\explore\ddeexec]
@="[ExploreFolder(\"%l\", %I, %S)]"

[HKEY_CLASSES_ROOT\Folder\shell\open\ddeexec]
@="[ViewFolder(\"%l\", %I, %S)]"

Amazing how simple a solution was required compared to the amount of effort needed to identify the cause of the problem. I still don't know what cause these registry keys to become corrupted in this way, but at least I know the fix for it in the future.

Astaec, seems that your Office 2000 install must have done something like this to your registry. Feel free to use the above patch to fix it.

The points go to LeeTutor for providing his fast original response, the reg exports from his machine, and for checking for differences (although you missed the vital ones :)

Thanks all.
0

Commented:
Good job Lee!
peterchamberlin glad yo got it working
Steve
0

retiredCommented:
Thank you, Peterchamberlin, for the points but also for providing all that good info for future readers of this question in the PAQs.  Thanks also, stevenlewis for your comment; and why haven't you replied to my email of some time ago?  Been too busy?  Or did it never arrive?
0

## Featured Post

• 10
• 6
• 3
• +3
Tackle projects and never again get stuck behind a technical roadblock.