Path not being searched...?!

[Homer J. Simpson]

Hi all,

Today I've noticed some strange problem, and the more I look at it the more
I'm getting convinced that something is *very* wrong with my system.

It started when I ran ipconfig from a command prompt:

"'ipconfig' is not recognized as an internal or external command, operable
program or batch file."

In other word, it couldn't find the ipconfig.exe.

Sure enough, it was in the system32 folder. I managed to run it from there
without any problem. I switched back to some other random folder, tried to
run it again, and sure enough, it failed with the same message.

'set path' showed that %SystemRoot%\system32 is part of the search path.
%SystemRoot% is correctly defined as D:\WINDOWS.

If I type in %SystemRoot%\system32\ipconfig, it runs fine.

WTH? Why isn't the search path being used all of a sudden?

I try running a few more EXEs that should be present in other folders
defined in the search path. Again, none of them can be found, including
others in system32 like Notepad and Calc. The files *are* there and can be
run if I either specify the full path or "CD [...]" to the appropriate
folder before.

Something even stranger--a good while ago (months) I added one more folder
(E:\Utils) to the end of the %PATH% environment variable, just so I have
quick access to a bunch of third-party utilities. I noticed that *they*
managed to run wherever I was, so I could only conclude that this folder
*was* being searched. Upon closer examination, I noticed that E:\Utils had
somehow *disappeared* from the %PATH% environment variable.

Just, wow. I'm dumbfounded. The problem still exists after a reboot.

Thoughts?

 

[XS11E]

"Homer J. Simpson" <root@127.0.0.1> wrote:

> Just, wow. I'm dumbfounded. The problem still exists after a
> reboot.
>
> Thoughts?

The usual, virus scan, malware scan, rootkit scan, dump the cache, etc.
see if anything turns up but I'm guessing you've already done all
this....





--
XS11E, Killing all posts from Google Groups
The Usenet Improvement Project: http://blinkynet.net/comp/uip5.html

 

[Homer J. Simpson]

>> Just, wow. I'm dumbfounded. The problem still exists after a
>> reboot.
>>
>> Thoughts?
>
> The usual, virus scan, malware scan, rootkit scan, dump the cache, etc.
> see if anything turns up but I'm guessing you've already done all
> this....

Yeah, I have. One thing I've noticed recently though, is that when I log
into Windows, the Security Center thingamabob pops up a warning in the
systray saying it can't find my antivirus (Grisoft AVG), although it's there
and running. OTOH if Security Center relies on the search path and that's
broken, then I could see why it would start complaining all of a sudden.

I've run full virus scans, WinDefender, etc, none of them report anything
out of the ordinary. I keep my system up to date religiously, and it's
sitting behind a router with a firewall. I don't see anything that seems
out of place with SysInternals' autoruns.exe. Their rootkit revealer
(v1.71) simply crashes--though that's not something new I've never got it
to run on XP x64.

 

[Tony Sperling]

Hmm - if you edited your search path, did you remember the 'semicolon'
everywhere except at the end?

Tony. . .


"Homer J. Simpson" <root@127.0.0.1> wrote in message
news:%231yhglovHHA.736@TK2MSFTNGP06.phx.gbl...
> Hi all,
>
> Today I've noticed some strange problem, and the more I look at it the
more
> I'm getting convinced that something is *very* wrong with my system.
>
> It started when I ran ipconfig from a command prompt:
>
> "'ipconfig' is not recognized as an internal or external command, operable
> program or batch file."
>
> In other word, it couldn't find the ipconfig.exe.
>
> Sure enough, it was in the system32 folder. I managed to run it from
there
> without any problem. I switched back to some other random folder, tried
to
> run it again, and sure enough, it failed with the same message.
>
> 'set path' showed that %SystemRoot%\system32 is part of the search path.
> %SystemRoot% is correctly defined as D:\WINDOWS.
>
> If I type in %SystemRoot%\system32\ipconfig, it runs fine.
>
> WTH? Why isn't the search path being used all of a sudden?
>
> I try running a few more EXEs that should be present in other folders
> defined in the search path. Again, none of them can be found, including
> others in system32 like Notepad and Calc. The files *are* there and can
be
> run if I either specify the full path or "CD [...]" to the appropriate
> folder before.
>
> Something even stranger--a good while ago (months) I added one more folder
> (E:\Utils) to the end of the %PATH% environment variable, just so I have
> quick access to a bunch of third-party utilities. I noticed that *they*
> managed to run wherever I was, so I could only conclude that this folder
> *was* being searched. Upon closer examination, I noticed that E:\Utils
had
> somehow *disappeared* from the %PATH% environment variable.
>
> Just, wow. I'm dumbfounded. The problem still exists after a reboot.
>
> Thoughts?
>
>

 

[Homer J. Simpson]

> Hmm - if you edited your search path, did you remember the 'semicolon'
> everywhere except at the end?

Yeah--but that was months ago, and I've run into this particular 'problem'
only today.

 

[Homer J. Simpson]

Just a follow up--it looks like this may be solved.

I found out that I had another one of my machines that exhibited the same
behavior. I then realized that there is one common program I installed
recently on both machines (and not others, which don't have that problem).
Just to confirm, I fired up a clean VM, verified I could access things in
system32, installed the program in it, then tried running programs from
system32 again--which now failed. Pretty much confirmed all I needed.

I made note of the PATH environment variable before and after installing the
program. Before installing it, the path was defined as:

D:\WINDOWS\system32\ [...tons of other entries...]

....whereas after installing the program, the path got changed to:

%SystemRoot%\system32\[...tons of other entries...][path to the newly
installed program]

The path added at the end doesn't seem to be the problem--it looks rather
that it's the %SystemRoot% substitution that's to blame. Looks like putting
an environment variable (%SystemRoot%) as part of the definition of another
(%Path%) isn't quite something you should be doing. To protect the
innocent, I won't name the program until I get in touch with its authors and
verify whether this is something they're aware or even heard of.

In the meantime...it looks like manually "fixing" the environment variable
takes care of the problem.

I hope this is useful to others.

 

[Charlie Russel - MVP]

Good followthrough. Much appreciated.

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Homer J. Simpson" <root@127.0.0.1> wrote in message
news:%23W2pvlrvHHA.3468@TK2MSFTNGP05.phx.gbl...
> Just a follow up--it looks like this may be solved.
>
> I found out that I had another one of my machines that exhibited the same
> behavior. I then realized that there is one common program I installed
> recently on both machines (and not others, which don't have that problem).
> Just to confirm, I fired up a clean VM, verified I could access things in
> system32, installed the program in it, then tried running programs from
> system32 again--which now failed. Pretty much confirmed all I needed.
>
> I made note of the PATH environment variable before and after installing
> the program. Before installing it, the path was defined as:
>
> D:\WINDOWS\system32\ [...tons of other entries...]
>
> ...whereas after installing the program, the path got changed to:
>
> %SystemRoot%\system32\[...tons of other entries...][path to the newly
> installed program]
>
> The path added at the end doesn't seem to be the problem--it looks rather
> that it's the %SystemRoot% substitution that's to blame. Looks like
> putting an environment variable (%SystemRoot%) as part of the definition
> of another (%Path%) isn't quite something you should be doing. To protect
> the innocent, I won't name the program until I get in touch with its
> authors and verify whether this is something they're aware or even heard
> of.
>
> In the meantime...it looks like manually "fixing" the environment variable
> takes care of the problem.
>
> I hope this is useful to others.
>

 

[Homer J. Simpson]

> Good followthrough. Much appreciated.

I think it's just common courtesy, not just for those following or
participating in a thread as it's being written, but also for those
searching for similar problems in the future. Even for embarassing "sorry,
it was totally my fault" type of problems.

There's few things I hate more than Googling for 20 minutes to *finally*
find a discussion that exactly describes a problem I'm having, and ends with
the original poster saying "never mind, I managed to fix it" without ever
describing the cause of the problem or its eventual solution.

 

[Charlie Russel - MVP]

I couldn't agree more.

--
Charlie.
http://msmvps.com/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Homer J. Simpson" <root@127.0.0.1> wrote in message
news:e4BDtTwvHHA.4916@TK2MSFTNGP04.phx.gbl...
>> Good followthrough. Much appreciated.
>
> I think it's just common courtesy, not just for those following or
> participating in a thread as it's being written, but also for those
> searching for similar problems in the future. Even for embarassing
> "sorry, it was totally my fault" type of problems.
>
> There's few things I hate more than Googling for 20 minutes to *finally*
> find a discussion that exactly describes a problem I'm having, and ends
> with the original poster saying "never mind, I managed to fix it" without
> ever describing the cause of the problem or its eventual solution.
>
>
>