c_strowbridge said in
I am running winxpsp1 on a brand new out the box dell dimesion 8300.
When logging into one of the users profiles, the system32 directory
will open during the startup process. I have checked the startup
directories for all users and the user in question. There is nothing
I can see that pertains to this directory. I have also tried to
remove all items the startup directories with no luck. Any help would
be appreciated.
Thanks,
Chad
Be careful when clicking on links at Kelly's site. Instead of
downloading the file, the link will *run* the program; i.e., the link
points to a .vbs or .reg file and you end up running it instead of
downloading it first (so you could then look inside the file to check
what it does). Right-click on her links and use Save Target As. If you
have the status bar displayed in IE, you can see what the link points to
and what filetype is used when you hover the mouse over the link.
A couple of other causes that I've experienced are installs that do not
put the correct and full path to the program in the startup path or they
don't enclose it within double quotes when there is a space in the path.
Run msconfig.exe and take a look at the startup programs. Msconfig will
show you the startup programs and services but note that there are other
places that can load programs on startup, like Task Scheduler and
startup scripts (and now some spyware is attaching themselves to
Winlogon\Notify events defined in the registry). Check if the following
are found:
- Only a path is specified, like "C:\Windows\System32". Could be they
forgot to add the program at the end of the path or it got truncated.
- A full path and filename are specified but they contain spaces and the
install program did not enclose that path with double quotes. For
example, if exist the paths of "C:\Program Files\nVidia" and "C:\Program
Files\nVidia Corporation" then an installer that adds:
C:\Program Files\nVidia Corporation\nvswap.exe /parm
(and NOT enclosed in double quotes) will end up having an Explorer
window open to "C:\Program Files\nVidia". The string gets parsed at the
space so the rest of the string thereafter is considered as parameters
to the first part of the string. In effect, the following gets
executed:
"C:\Program Files\nVidia" "Corporation\nvwap.exe" "/parm"
In fact, if you have a subdirectory named "C:\Programs" in addition to
the standard one named "C:\Program Files" then the short-circuit occurs
even earlier and you get the effect of:
"C:\Program" "Files\nVidia Corporation\nvswap.exe" "/parm"
So enclose the executable portion of the string withing double quotes,
as in:
"C:\Program Files\nVidia Corporation\nvswap.exe" /parm
Microsoft (and Unix) allow spaces within names for files and folders but
it is a stupid idea to use them because spaces will screw up lots of
programs, even the command interpreter. Although allowed in Unix, I
don't remember if there are many directories and files that actually end
up with spaces in them (but instead use the "_" character to represent a
space). However, in Windows, there are lots of directories and files
that have spaces in them, like:
C:\Program Files
C:\Program Files\Common Files
C:\Documents and Settings
C:\Documents and Settings\<account with spaces>\Application Data\...
C:\Windows\Downloaded Installations
and many others, all of which could have used camel notation (i.e.,
capitalize the first character of every word, as in
C:\ProgramFiles\CommonFiles) or used a non-whitespace character to
separate the words (as in C:\Program_Files\Common_Files). Even in a DOS
shell, you cannot enter:
dir C:\Program Files\Common Files
but have to override the default of space-delimited parsing and enter:
dir "C:\Program Files\Common Files"
The other way to bypass the space-delimited parsing is to use the 8.3
DOS name for the file or folder, so instead you would use:
dir C:\Progra~1\Common~1
But who the hell wants to bother to open a DOS shell to run "dir /x" to
find out what are the 8.3 names? I don't mind long names but it is
stupid to include spaces. This isn't just a Microsoft stupidity (in NOT
following the Unix standard) as I first hit this nuisance when using
Unix (and before Windows supported long filenames).
It is unlikely that having spaces in the path or filename is the cause
of your particular problem. C:\Windows\System32 doesn't have any spaces
and usually the files and subdirectories under it do not employ spaces
in their names. However, for example, I do have a
"C:\WINDOWS\system32\windows media", so not enclosing it within double
quotes could result in truncating the path at the first space.
