dexter.inside

hehe, I see you like NT 5.x being deployed with the beta-1 WIM and the longhorn setup. I like it better than Norton Ghost so here's the other possible bugs i've been investigating this week: 1) Media Center is missing .NET 1.0.3705 There's this Media Center problem that keeps annoying me.... vLite has removed a certain component (not sure which) that has also removed the following: (as stated by HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs) \Windows\Microsoft.NET\Framework\v1.0.3705\mscorrc.dll \Windows\Microsoft.NET\Framework\v1.0.3705\mscorsec.dll \Windows\Microsoft.NET\Framework\v1.0.3705\microsoft.vsa.vb.codedomprocessor.dll \Windows\Microsoft.NET\Framework\v1.0.3705\microsoft.jscript.dll \Windows\Microsoft.NET\Framework\v1.0.3705\iehost.dll \Windows\Microsoft.NET\Framework\v1.0.3705\pxwma.dll \Windows\Microsoft.NET\Framework\v1.0.3705\pxcpyi64.dll \Windows\Microsoft.NET\Framework\v1.0.3705\system.data.dll \Windows\Microsoft.NET\Framework\v1.0.3705\diasymreader.dll \Windows\Microsoft.NET\Framework\v1.0.3705\wminet_utils.dll \Windows\Microsoft.NET\Framework\v1.0.3705\mscorrc.dll \Windows\Microsoft.NET\Framework\v1.0.3705\system.configuration.install.dll \Windows\Microsoft.NET\Framework\v1.0.3705\mscordbi.dll \Windows\Microsoft.NET\Framework\v1.0.3705\system.enterpriseservices.dll \Windows\Microsoft.NET\Framework\v1.0.3705\vsavb7rt.dll I do not think that it was your intention to cripple the 1.0.3705 .NET, so something is odd here. Furthermore, pxwma.dll is required AFAIK by a certain part of the WMFDIST11, and I think it is related to the MPEG playback problem. Media Center crashes due to not being able to perform it's scrpting operations via the missing DLLs. 2) There's a missing assembly that shouldn't be missing I think Windows Servicing Stack causes problems to the prefetch funtionality due to the absence of \Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.0.6000.16386_none_07289f4cca5f6990 I am not getting a Event Viewer response on this. More people should check this. Check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Version\6.0.6000.16386 3) Windows Help files are still registered for a MMC snap-in Specifically, MSCs that load these three snap-ins cause small delays (the "adding snap-in" notification) because of: \Windows\Help\eventviewer.chm in HKLM\Microsoft\MMC\SnapIns\FX:{b05566ad-fe9c-4363-be05-7a4cbb7cb510}\LinkedHelpTopics \Windows\Help\taskscheduler.chm in HKLM\Microsoft\MMC\SnapIns\FX:{c7b8fb06-bfe1-4c2e-9217-7a69a95bbac4}\LinkedHelpTopic \Windows\Help\taskscheduler.chm in HKLM\Microsoft\MMC\SnapIns\FX:{c7b8fb07-bfe1-4c2e-9217-7a69a95bbac4}\LinkedHelpTopic My Event Viewer is significantly slower when using it than the rest of compmgmt.msc components 4) Windows Sounds removing Windows Sounds does not remove these: \Windows\media\tada.wav in HKU\AppEvents\Schemes\Apps\Explorer\FaxSent\.default \Windows\media\ding.wav in HKU\AppEvents\Schemes\Apps\Explorer\FaxError\.default 5) Removal of Windows Error Reporting should also remove the WER registration (user-account)\AppData\Local\Microsoft\Windows\WER\ReportQueue is no longer created so HKLM\Software\Microsoft\Windows\CurrentVersion\explorer\VolumeCaches\Windows Error Reporting Queue Files\Folder should be removed in order to prevent the ReadyBoost service to cache it. I also think that this is related to HKLM\Software\Microsoft\Windows NT\CurrentVersion\APITracing\LogFileDirectory I still have arround 80 extra issues that I am investigating this week. I will continue the listing when I will have more time. P.S. This thread is way more entertaning than the one that I've been seeing for the past 8 months in Vista Beta

Bug report for vLite 0.6 When removing Search Indexer, besides \Windows\winSxS\x86_windowssearchengine.resources_31bf3856ad364e35_6.0.6000.16386_en-us_8cee37712b17ca53 these file is also removed: \Windows\System32\tquery.dll that is required by Microsoft Sysprep 3.14 One of the sysprep plugins in Vista RTM uses tquery.dll and its \En-US\tquery.dll.mui from System32. The assembly itself is safe to remove. The workaround is to manually restore them from the original WIM.

You tried looking in DirectX redist? there's a BDA.CAB there, maybe it contains what you need

They still use ximage, though.... have a look in Windows XP Fundamentals (Codename Eiger)

Unfortunately, it just looks cool... but it's not a cool application. I have a SVN repository on Google Code for it and I will probably need a lot of help in order to achieve something that complex. Try programming for .NET Framework 2.0... all your apps will look cool. I really doubt that by myself I can finish this thing in under 1 year

I've been closely following the evolution of nLite for the past time... I am also considering to write my own C# applications to modify windows images that have been hardware-generalised using Microsoft Sysprep, like Vista and images taken after running sysprep -reseal on XP/2003. I've also been studying how Vista is built (all the way back to build 4029) and would like to describe the main issues of doing a complex operation like nLitening a OS image: - Vista installation DVD is actually a sysprepped image of another running Vista installation from a technician's computer. Run sysprep on any NT 5.x builds and you would have virtually the same thing. So any user application that would want to modify it can follow one of these 2 general layouts: 1) The direct method (like nLite works today) - mount a WIM image for read/write operations - load the registry hives in the active registry - perform the removals for files and registry settings - unload the hives - commit and unmount the WIM image 2) The indirect method (like in Windows XP Embedded) - develop a method for reversing the modularization of windows (the opposite of Embedded Target Designer) - transform the contents of a generalized Vista WIM image in modules, stored in a local repository - add / remove components in the local repository - regenerate the generalized WIM image I think both of these methods can be applied on resealed XP/2003 images, allowing WIM deployment for them. This would result in a successor of nLite capable of working with both XP/2003 and Vista. Also, it would allow experimenting on XP, which takes a lot less time to test. Playing with 8 gigs of data when testing is not nice. Here's a screenshot from my application, it's not much .... I've been working on it scarcely in the past 2-3 weeks I'd use the following layout for modules, in a similar way Target Designer for Windows XP Embedded works: 1) a set of "primitives", consisting in - a EXE / DLL file stripped of resources - separate resources, like ResHacker.exe extracts them (good for applying resource patches very fast, for example XPize could just update the primitive resources instead of unpacking / repacking everything) - maybe some INFs to be used with regsrv32 2) a set of "components" consisting in - one or more primitives - registry settings 3) a set of "features" - one or more components - one or more primitives - scripts, user files ... For example a primitive would be SHELL32.DLL and it's stripped resources, a component would be the explorer shell and a feature would be Windows Media Player. Store all these in a repository using the WIM technology and you'd get a lightning-fast Vista reconstruction engine