This is a great fix. I originally found it on MS's site (
http://support.microsoft.com/kb/314060/EN-US/ ) about a year ago and it worked great for me....
This seems to happen on loads of Dell 'D' series Latitude notebooks. This could just be my perception of the issue though as all we use is Dell Latitudes. I am the only remote support tech for a company that has about 400+/- notebook users (not all notebook users are remote users though).
The first time I saw the issue I was completely baffled, and since I have been doing this for a while (14+ years) that doesn’t happen often. Anyway once I corrected it I had no time to 'play' as the user really wanted their system back. I did recreate the bad registry entries on another identical system. However the drive was still there and I couldn’t actually recreate the problem.
Today I ran into this again while porting a D600 image to a Dell D610. After futzing with it for a while my memory finally kicked in and I looked up my notes on the problem. I first exported the entire registry key at [tt]{4D36E965-E325-11CE-BFC1-08002BE10318}[/tt]. I then deleted the value data for both keys (NOT the values themselves) and (of course) it worked. Since I was now confident that I could fix the problem I decided that I wanted to play with it and see if I could come up with anything.
I imported the 'crap' code back in, rebooted and the issue was here again. In this particular XP load the registry is calling 'Cdr4_xp.sys' for the LowerFilters and 'pwd_2.sys' (read on about this file) for the UpperFilters value data. So I surmised that one of these files was corrupted and when the VXD loads it was causing the problem. I removed the first value data field of 'Cdr4_xp' and rebooted...the problem was still there. I replaced the buggy reg entry again and removed reference to the second value data field of 'pwd_2' and again rebooted the system. Still nothing; no drive will recognize.
So I decided that I would compare these files to my system (which doesn't and has never had this problem). I pulled up the properties for 'Cdr4_xp' and compared these with the file on my system. Same file version and size. So I went looking for 'pwd_2' and low and behold here is a surprise. I didn’t have this file at all. So I checked the 'problem' computer and it didn't have this file either! I did however have 'pwd_2k.sys" in the [tt]C:\windows\system32\drivers\[/tt] folder.
I *thought* (we all know where thinking gets us) that had I found the problem. My theory was that somehow the registry got ganked up and it’s calling the file by the wrong name (calling 'pwd_2' instead of 'pwd_2k'). I made the registry change to add the 'k' and now the value data is actually associating with a file. I rebooted the system (all smug and confident that I found the real problem) expecting the drive to work just fine; WRONG! The same problem....
At this point I decided that I would copy all the drivers and the registry key from my system (the one without the issue) to the problem system. After importing the files and reg key I checked the key and, yep, the key now matches my 'known good' setup. Rebooted the system and the @#$%in issue is still happening! At this point I decided I had followed the rabbit trail enough and decided to call it quits. I deleted my now heavily modified value data fields for UpperFilters and LowerFilters and shut the system down. Something stuck in my mind though and after writing most of this post I decided to double check my work. I rebooted the system. I was glad that I did! The value data entry’s for these values were now blank - but the drive again wouldn't work! I had to re-import the original registry settings, reboot, remove the value data entry’s again, and reboot again to correct the problem. It seems on this one XP didn't really care that the fields were blank; it only worked when I deleted the original value data info! Now that is WIERD!
Oh well! Wish I could have solved it for real. I am stashing this one away as a rainy day problem..... This is a great fix. I originally found it on MS's site (
http://support.microsoft.com/kb/314060/EN-US/ ) about a year ago and it worked great for me....
This seems to happen on loads of Dell 'D' series Latitude notebooks. This could just be my perception of the issue though as all we use is Dell Latitudes. I am the only remote support tech for a company that has about 400+/- notebook users (not all notebook users are remote users though).
The first time I saw the issue I was completely baffled, and since I have been doing this for a while (14+ years) that doesn’t happen often. Anyway once I corrected it I had no time to 'play' as the user really wanted their system back. I did recreate the bad registry entries on another identical system. However the drive was still there and I couldn’t actually recreate the problem.
Today I ran into this again while porting a D600 image to a Dell D610. After futzing with it for a while my memory finally kicked in and I looked up my notes on the problem. I first exported the entire registry key at [tt]{4D36E965-E325-11CE-BFC1-08002BE10318}[/tt]. I then deleted the value data for both keys (NOT the values themselves) and (of course) it worked. Since I was now confident that I could fix the problem I decided that I wanted to play with it and see if I could come up with anything.
I imported the 'crap' code back in, rebooted and the issue was here again. In this particular XP load the registry is calling 'Cdr4_xp.sys' for the LowerFilters and 'pwd_2.sys' (read on about this file) for the UpperFilters value data. So I surmised that one of these files was corrupted and when the VXD loads it was causing the problem. I removed the first value data field of 'Cdr4_xp' and rebooted...the problem was still there. I replaced the buggy reg entry again and removed reference to the second value data field of 'pwd_2' and again rebooted the system. Still nothing, no drive will not recognize.
So I decided that I would compare these files to my system (which doesn't and has never had this problem). I pulled up the properties for 'Cdr4_xp' and compared these with the file on my system. Same file version and size. So I went looking for 'pwd_2' and low and behold here is a surprise. I didn’t have this file at all. So I checked the 'problem' computer and it didn't have this file either! I did however have 'pwd_2k.sys" in the C:\windows\system32\drivers\ folder.
I *thought* (we all know where thinking gets us) that had I found the problem. My theory was that somehow the registry got ganked up and it’s calling the file by the wrong name (calling 'pwd_2' instead of 'pwd_2k'). I made the registry change to add the 'k' and now the value data is actually associating with a file. I rebooted the system (all smug and confident that I found the real problem) expecting the drive to work just fine; WRONG! The same problem....
At this point I decided that I would copy all the drivers and the registry key from my system (the one without the issue) to the problem system. After importing the files and reg key I checked the key and, yep, the key now matches my 'known good' setup. Rebooted the system and the @#$%ing issue is still happening! At this point I decided I had followed the rabbit trail enough and decided to call it quits. I deleted my now heavily modified value data fields for UpperFilters and LowerFilters and shut the system down. Something stuck in my mind though and after writing most of this post I decided to double check my work. I rebooted the system. I was glad that I did! The value data entry’s for these values were now blank - but the drive again wouldn't work! I had to re-import the original registry settings, reboot, remove the value data entry’s again, and reboot again to correct the problem. It seems on this one XP didn't really care that the fields were blank; it only worked when I deleted the original value data info! Now that is WIERD!
Oh well! Wish I could have solved it for real. I am stashing this one away as a rainy day problem.....
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7