Minkus

Hi, Many thanks to John for posting the above information - it worked in my case as well, fixing problems with KB938127 (MS07-050) failing to install on a machine with IE7 integrated into XP. I would just like to add two points from my own experience. Firstly, you already have a machine set up which is demonstrating this problem, it can be fixed by running 'sfc /scannow' at the command prompt - this will cause all of the relevant files in dllcache to be overwritten with the correct versions, and you should be able to install the IE updates. Of course you may need the XP CD inserted for this to work properly. Secondly, the file list which Jon supplied is (I believe) incomplete. There is an installation log file created in the Windows directory called 'ie7.log', and if you search through this file for the string 'dllcache', you will find the following list of files, which I think is more definitive. Extra entries are in bold: C:\WINDOWS\system32\dllcache\admparse.dll C:\WINDOWS\system32\dllcache\advpack.dll C:\WINDOWS\system32\dllcache\browseui.dll C:\WINDOWS\system32\dllcache\corpol.dll C:\WINDOWS\system32\dllcache\custsat.dll C:\WINDOWS\system32\dllcache\dxtmsft.dll C:\WINDOWS\system32\dllcache\dxtrans.dll C:\WINDOWS\system32\dllcache\extmgr.dll C:\WINDOWS\system32\dllcache\hmmapi.dll C:\WINDOWS\system32\dllcache\ie4uinit.exe C:\WINDOWS\system32\dllcache\ieakeng.dll C:\WINDOWS\system32\dllcache\ieaksie.dll C:\WINDOWS\system32\dllcache\ieakui.dll C:\WINDOWS\system32\dllcache\iedkcs32.dll C:\WINDOWS\system32\dllcache\iedw.exe C:\WINDOWS\system32\dllcache\ieencode.dll C:\WINDOWS\system32\dllcache\iepeers.dll C:\WINDOWS\system32\dllcache\iernonce.dll C:\WINDOWS\system32\dllcache\iesetup.dll C:\WINDOWS\system32\dllcache\iexplore.exe C:\WINDOWS\system32\dllcache\imgutil.dll C:\WINDOWS\system32\dllcache\inetcpl.cpl C:\WINDOWS\system32\dllcache\inseng.dll C:\WINDOWS\system32\dllcache\jscript.dll C:\WINDOWS\system32\dllcache\jsproxy.dll C:\WINDOWS\system32\dllcache\licmgr10.dll C:\WINDOWS\system32\dllcache\mshta.exe C:\WINDOWS\system32\dllcache\mshtml.dll C:\WINDOWS\system32\dllcache\mshtml.tlb C:\WINDOWS\system32\dllcache\mshtmled.dll C:\WINDOWS\system32\dllcache\mshtmler.dll C:\WINDOWS\system32\dllcache\msls31.dll C:\WINDOWS\system32\dllcache\msrating.dll C:\WINDOWS\system32\dllcache\mstime.dll C:\WINDOWS\system32\dllcache\occache.dll C:\WINDOWS\system32\dllcache\pngfilt.dll C:\WINDOWS\system32\dllcache\shdocvw.dll C:\WINDOWS\system32\dllcache\shlwapi.dll C:\WINDOWS\system32\dllcache\tdc.ocx C:\WINDOWS\system32\dllcache\url.dll C:\WINDOWS\system32\dllcache\urlmon.dll C:\WINDOWS\system32\dllcache\vbscript.dll C:\WINDOWS\system32\dllcache\VGX.dll C:\WINDOWS\system32\dllcache\webcheck.dll C:\WINDOWS\system32\dllcache\wininet.dll I have checked and some of these files are left in an inconsistent state (old version in dllcache rather than the new one) if they are not created before running the IE7 installer in svcpack.inf as described by Jon. Therefore although there are no known problems with using the list with the current updates, it might be best if anyone using these instructions in future used the updated list instead of the existing one. Whether Jon would be kind enough to update his patch to reflect this is up to him Kind regards, Chris Hill

Hi, Just to confirm what strel said - I have just tested the .NET Framework 3.5 Service Pack 1 (Full Package) installer in svcpack.inf, and so long as you use the usual ErrorReporting\DW and SystemSetupInProgress fixes from the .NET Framework 2.0, it works fine without breaking WebClient. It appears that, while the installer still causes the LocalService profile to be created 'early' at T-13, it also causes the 'Temporary Internet Files' folder to be created inside that profile, and so the WebClient service is able to start as it should. However there is still the issue that the LocalService profile is created earlier than it ought to be in the Windows installation process as a result of the .NET Framework installer, so it may still be advisable to insert the following line into a CMD file and execute it via svcpack.inf after the main dotnetfx35.exe installer: rmdir /S /Q "%ALLUSERSPROFILE%\..\LocalService" As I explained in my original post, this command will remove the 'stunted' LocalService profile, so that it can be 'recreated' at the correct point once Setup resumes. This command should not be run at any time apart from in svcpack.inf, as it will break your system, but it will prevent any potential issues that might occur from having a 'stunted' LocalService profile which may not be immediately apparent. I am deploying the .NET Framework 3.5 SP1 onto all the computers on my network using this command, and I cannot see any side effects at the moment. I hope this helps, and let me know how you get on! Kind regards, Chris

Hi, Just to say that I've now found a fix for the WebClient issue when deploying the .NET Framework 3.0+ via svcpack.inf: http://www.msfn.org/board/index.php?showtopic=131332 Kind regards, Chris

Hi, I am hoping this post is going to make some people very happy. I have found a fix for the issue where deploying the .NET Framework 3.0 at T-13 via svcpack.inf causes WebClient 87 errors when the computer is restarted. For those of you who just want to know what the fix is, you just need to add the following line to a CMD file and then execute it via svcpack.inf AFTER the .NET Framework 3.0 installation takes place: mkdir "%ALLUSERSPROFILE%\..\LocalService\Local Settings\Temporary Internet Files" (This is in addition to the other .NET Framework 2.0/3.0 fixes) This fix will also work if you have a computer which is already displaying this issue - i.e. if you run this command on a computer that has the WebClient errors now, it *should* fix them. For those of you who want to know how I found this out, here goes: Basically I work at a school where we use RIS and Group Policy to deploy stuff, and one of the things that I started doing recently was to deploy the .NET Frameworks as part of svcpack.inf instead of using Group Policy so that the files would be already 'in place' after the first reboot, a task which was made much easier by the advice and support provided on the forums here at msfn.org as well as other places online (thanks!) Well recently I found some software that required the .NET Framework 3.0, and so I wanted to add it to our svcpack.inf so that it was in place before Group Policy attempted to do the installation. I did already know about the issues deploying the .NET Framework 2.0 via svcpack.inf through reading Aaron Stebner's weblog, and also about the WebClient issue, but I thought I would give it a go. To my surprise although I did get the WebClient errors on the *first* reboot after the installation, I did not get them on *subsequent* reboots, unlike everyone else - at the time I didn't think too hard about this & just counted myself lucky. However recently we upgraded our virus scanner at school from VirusScan Enterprise 7.1 to VirusScan Enterprise 8.5, and after removing VSE 7.1 from our Group Policy Software Installation objects, I noticed that *new* computer installations were coming up with the dreaded 'WebClient' errors *every time* they booted, instead of just once at the first boot - aargh! Event Type: Error Event Source: Service Control Manager Event Category: None Event ID: 7016 Description: The WebClient service has reported an invalid current state 87. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Event Type: Error Event Source: Service Control Manager Event Category: None Event ID: 7022 Description: The WebClient service hung on starting. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. I quickly put my 'troubleshooting' hat on and tried to work out what had changed. As it turns out, it appears that when VirusScan Enterprise 7.1 was installed, it was creating a 'Temporary Internet Files' folder in the LocalService profile which hadn't existed there before. I investigated futher and found out that this folder would normally exist on a computer after a clean installation of Windows, but that for some reason installing the .NET Framework 3.0 using svcpack.inf at T-13 prevented this, and hence the errors were occuring. Creating the folder again resolved all of the problems and WebClient would start up perfectly. So I had my fix, but I still wanted to understand the problem more, so I delved deeper into the workings of Setup and .NET Framework 3.0. I altered svcpack.inf to load up a command prompt (using cmd.exe) just before and just after the .NET Framework 3.0 install took place at T-13, and took file listings and a registry dump before and after the installation (using 'dir' and 'reg'), so that I could find out what had changed. What I discovered was that before the .NET Framework 3.0 installs, the only folders (hidden or otherwise) under C:\Documents and Settings are the 'All Users' and 'Default User' folders - there are no profiles for LocalService and NetworkService as there are once Setup has completed. However, *after* the .NET Framework 3.0 installation takes place, the LocalService profile *has* been created, but only partially - presumably it only contains the contents of the 'template' Default User profile as it stands at that point in Windows Setup, which means not all of the 'normal' folders have been created, and one of those which is missing is 'Local Settings\Temporary Internet Files'. This causes a problem with WebClient (a service that runs using the LocalService profile) when it starts up, presumably because it needs the folder, but is not 'clever' enough to create the folder if it doesn't exist. However, if we create the folder ourselves, then WebClient is 'clever' enough to create everything that goes *inside* that folder & set it up properly, so the problem is resolved. I mention this because there is another way to 'fix' the problem which also works and may be a bit 'cleaner', and yet IMO also carries some risk. It is also possible to execute the following command after the .NET Framework 3.0 setup completes: rmdir /S /Q "%ALLUSERSPROFILE%\..\LocalService" and the problem will be resolved; since the LocalService profile is not 'meant' to exist at the T-13 stage of setup, we can safely delete it, and it will be recreated at the 'correct' point in Setup later on, and it *will* contain the 'Temporary Internet Files' folder. I have tested this fix as well and it seems to work. However this approach does contain some drawbacks in my point of view: It presumes that the .NET Framework 3.0 setup has not written anything 'important' to the LocalService profile which is needed in order for the .NET Framework 3.0 to work. Even if the .NET Framework 3.0 does not write anything important, it assumes that *future* versions of the .NET Framework will also not write anything important. It is not possible to use this command to 'fix' an existing 'broken' WebClient install once Setup has completed - in fact it will probably make things much worse. I mention it here in case people are interested in an alternative way to fix the problem, since as things stand if you use the 'mkdir' fix to install the .NET Framework 3.0 in svcpack.inf your system will be running with a slightly 'stunted' copy of the LocalService profile which may not contain all of the folders & registry settings that would have been created as part of a 'normal' Windows install - so your mileage may vary. Having said that we have been effectively running all of our 400-odd computers with this 'fix' for some time now (due to VirusScan Enterprise 7.1 creating this directory for us), and so I have no reason to believe that there are will be any problems caused by this, even if it is not the 'cleanest' solution. I hope this helps a lot of you resolve one of those really annoying problems that has been bugging us for some time; please let me know how you get on! Also I have not tested this fix with any versions of the .NET Framework later than 3.0 - I leave it to you all to find out if this 'fix' helps with 3.0, 3.5 and 3.5 SP1! Thanks for reading, and kind regards, Chris

Hi, I had this problem, and ended up discovering that it was because I was trying to run setup.exe direct from a CD, rather than from a local (or network) copy of the CD. It appears that you have to be able to write to the location where setup.exe is run from in order for the /CreateTransform switch to work. Once I copied the contents of the CD to the hard drive (and un-set the 'Read Only' attribute if it gets set in the process), then the transform creation process worked fine for me. Have emailed Aaron Stebner at Microsoft to let him know about this, so he might post this to his blog at some point. By the way, I didn't find this out on my own - was tipped off by misterd's post at AppDeploy (under the 'Notes' section, under 'Gotchas'). Hope this helps!