Let me start out by saying, this isn't like the other thread that went on for 9 months and is still active!
I have ~600 desktop PC's and ~100 workstations that are affected with this condition.
The PC's are running out of the box (IBM 1.8GHz & Compaq Dual Xeon 2.2Ghz):
W2K
IE 5.5 SP2
MS Office 2000 SR1a (all patches except Outlook attachment stripper)
Adobe Reader 5
MySAP
McAfee 4.5.1
ViewNow for 3270 emulation
QvtNet for VT terminal emulation
Problem:
Everybody gets attached to their personal share on a server via a login script which is a mapped as network drive 'Z.' If they bring up Windows Explorer highlight a folder one level deep or deeper to view the contents of that folder and select Edit from the file menu (as if going to do an Edit/Select all), they get an explorer.exe crash. If they are in the root level z:\server name\program area\username and they have that highlighted and do Edit, it works fine.
History:
Machines were imaged using Norton Ghost 7.5. Sysprep was used as required for SID changing. This is the first year we used Norton's suggestion of creating a local user and giving it admin rights to do the build/customizations and then copying it to the default user profile, and permitting Everybody to use it.
Troubleshooting steps taken:
- Machines have been fully updated SP3, IE 6, all hot fixes and critical updates.
- Not privilege issue trouble exists for admin or general user
- Not profile specific, all domain accounts on machine exhibit the condition
- I have copied the local administrator ntuser.dat file into my domain profile via a remote machine, and this does solve the problem. However for the people that have been using these machines for a couple months they would lose all their customizations or installed applications since the standard image.
- Based upon the above finding, I presumed that it must be registry permission related. As a quick and dirty attempt, we gave Everyone full control to the entire registry. Did not solve the problem.
I took one of the PC's and hand installed all the same applications and cannot reproduce the error. Leading me to believe now that it might have to do with an order of installation. There is a TN article (Q326612) for explorer.exe causing errors when you attempt to install SP3. While this isn't an SP3 installation issue, the article raises a question. The mshtml.dll file they reference as not being updated, appears to not be updated even in a succesful install of SP3. The file date on the original image is 8/17/2001. mshtml.dll is part of SP3, with a file date of 7/23/2002. This file does not get updated by the install.
So I tried renaming the file in dllcache so it could not replace it when I deleted the original from system32. I went to a remote machine then and deleted the file from the system32 folder. Logged back into the machine and unregistered the dll. I then went and applied the service pack again and the dll was updated. However there are other dll files with similar file names which might be dependant upon that file which do not appear to be replaced. So now when I browse to the system32 folder, it brings up no file listing. Of course I can go back and repair the file and the file listing comes back. Regardless of which dll is there, the problem still exists anyway.
Any ideas? Matt
I have ~600 desktop PC's and ~100 workstations that are affected with this condition.
The PC's are running out of the box (IBM 1.8GHz & Compaq Dual Xeon 2.2Ghz):
W2K
IE 5.5 SP2
MS Office 2000 SR1a (all patches except Outlook attachment stripper)
Adobe Reader 5
MySAP
McAfee 4.5.1
ViewNow for 3270 emulation
QvtNet for VT terminal emulation
Problem:
Everybody gets attached to their personal share on a server via a login script which is a mapped as network drive 'Z.' If they bring up Windows Explorer highlight a folder one level deep or deeper to view the contents of that folder and select Edit from the file menu (as if going to do an Edit/Select all), they get an explorer.exe crash. If they are in the root level z:\server name\program area\username and they have that highlighted and do Edit, it works fine.
History:
Machines were imaged using Norton Ghost 7.5. Sysprep was used as required for SID changing. This is the first year we used Norton's suggestion of creating a local user and giving it admin rights to do the build/customizations and then copying it to the default user profile, and permitting Everybody to use it.
Troubleshooting steps taken:
- Machines have been fully updated SP3, IE 6, all hot fixes and critical updates.
- Not privilege issue trouble exists for admin or general user
- Not profile specific, all domain accounts on machine exhibit the condition
- I have copied the local administrator ntuser.dat file into my domain profile via a remote machine, and this does solve the problem. However for the people that have been using these machines for a couple months they would lose all their customizations or installed applications since the standard image.
- Based upon the above finding, I presumed that it must be registry permission related. As a quick and dirty attempt, we gave Everyone full control to the entire registry. Did not solve the problem.
I took one of the PC's and hand installed all the same applications and cannot reproduce the error. Leading me to believe now that it might have to do with an order of installation. There is a TN article (Q326612) for explorer.exe causing errors when you attempt to install SP3. While this isn't an SP3 installation issue, the article raises a question. The mshtml.dll file they reference as not being updated, appears to not be updated even in a succesful install of SP3. The file date on the original image is 8/17/2001. mshtml.dll is part of SP3, with a file date of 7/23/2002. This file does not get updated by the install.
So I tried renaming the file in dllcache so it could not replace it when I deleted the original from system32. I went to a remote machine then and deleted the file from the system32 folder. Logged back into the machine and unregistered the dll. I then went and applied the service pack again and the dll was updated. However there are other dll files with similar file names which might be dependant upon that file which do not appear to be replaced. So now when I browse to the system32 folder, it brings up no file listing. Of course I can go back and repair the file and the file listing comes back. Regardless of which dll is there, the problem still exists anyway.
Any ideas? Matt
