cluberti

Fair enough, but I think my previous point still stands. If you can, set up a lab and get your hands dirtier with KMS for Windows and Office, as that's the best way to learn. In general, that's how I did it, and I know a few others here with KMS experience who did it this way as well. When you have a question about something, go break it in the lab!

Why is it people can't find it in themselves to follow the licensing agreements they agree to, nor copyright, nor further the forum rules here? I guess if you aren't going to follow EULAs with software from major corporations or honor their legal copyright, you're not going to follow one for something like nLite - and you certainly aren't going to follow some little forum's rules. Except, that gets you a one-way ticket out of here. Copyright is something the Netherlands upholds in it's IP laws (meaning copying that Windows CD by downloading it was a violation of copyright), and IP laws in the Netherlands also protect EULAs like nLite's (thus using it against the EULA is also a no-no, even in your country). Sorry, Attended. You fail x3, you're gone. In one post, no less. [Closed].

Install the gvlk keys listed here to change from MAK to KMS, and then run slmgr /ato to activate. Yes, but you should run slmgr -upk to remove the old key and activation information first. No, you should not be activating your Windows 7 images before you run sysprep /generalize, because it's going to remove the activation anyway - this is one of the reasons Microsoft provides the "default" keys to begin with. As with Office, you shouldn't be activating your Win7 installation before sysprep, making this a moot point. Also, make sure to build and deploy your Windows 7 images using the gvlk key from the article llinked above to avoid problem #1 you posted in the first place. If you build with the gvlk key, no. Yes, although again I would check your key to make sure it's the gvlk key from Technet (or, technically, \sources\product.ini from the installation media). I wrote a vbscript a while ago that gathers this (and other) information from a Windows install, so you can use that as you wish to accomplish this if need be. For domain-joined machines, yes. However, if the machine is not domain-joined, you will have to run -skms to get it to work properly due to permissions on the SRV record created when you installed KMS. This is not possible with slmgr.vbs. This is what VAMT is for, use it.Honestly, everything you asked is answered on Technet or MSDN, so I suggest you work on your Technet/MSDN search-fu before asking more VLK and activation questions here in the future. You could have saved yourself quite a bit of time if you had.

Well, if that's the case, then it *is* one of your device drivers, likely . At least you've ruled that out.

If you want things to work without manual registry edits (which is a PITA, by the way), you are really going to have to call Win32 APIs to make it happen (which is what device drivers do). What specifically are you trying to do?

0: kd> kn # ChildEBP RetAddr 00 9fccfa58 8062faba nt!HvpGetCellMapped+0x5f 01 9fccfa74 80638c4e nt!CmpMarkValueDataDirty+0x44 02 9fccfa90 80638ef3 nt!CmpMarkKeyValuesDirty+0xcc 03 9fccfaac 80638f90 nt!CmpFreeKeyValues+0x17 04 9fccfae8 806397ce nt!CmpSyncKeyValues+0x26 05 9fccfb2c 80639941 nt!CmpCopySyncTree2+0x1f4 06 9fccfb5c 80626042 nt!CmpCopySyncTree+0x4f 07 9fccfccc 8062193a nt!CmpSaveBootControlSet+0x2b0 08 9fccfcdc 8054161c nt!NtInitializeRegistry+0x5e 09 9fccfcdc 8050046d nt!KiFastCallEntry+0xfc 0a 9fccfd58 8054161c nt!ZwInitializeRegistry+0x11 0b 9fccfd58 7c90e4f4 nt!KiFastCallEntry+0xfc WARNING: Frame IP not in any known module. Following frames may be wrong. 0c 0007fe8c 00000000 0x7c90e4f4 A crash like this, especially in HvpGetCellMapped, is going to be caused by pool corruption, likely by an installed kernel-mode filter driver. You have a bunch loaded that are non-Microsoft, including what appears to be an AVG Intrusion Detection filter. It might be interesting to uninstall that application, or at least keep it's driver from loading, to see if you can't get yourself back into your box. The others all appear to be standard device drivers, and while they could be culprits, I generally like to see Intrusion Detection software removed when a box becomes unbootable before I go blaming device drivers, especially if the system worked fine for a period of time with these drivers installed and then suddenly starts failing. Usually the only thing updated on a system regularly, other than Microsoft components via WU, is definitions for antivirus or ID software. If a device driver was going to cause it, it would likely do so fairly quickly after install. Also, if safe mode works but regular boot does not, it would generally mean it's not a RAM issue either (it should still fail in safe mode if the RAM was really going bad, most likely).

The SMBus is usually for system management communications between BIOS and devices like fans, batteries, chassis intrusion, laptop sensors, etc. I've seen some PCI cards that had SMBus extensions, but they weren't required, and I've never seen a card reader or USB port that was not on the USB controller bus as a hub or root device - if all of your USB buses are working, you should be fine. Also, the SMBus is an interrupt bus, whereas the USB bus is a polling bus.

Yeah, it's late . Good catch.

This error is indicating a hardware error, as reported by Processor 0: 1: kd> !errrec fffffa80055528f8 ... =============================================================================== Section 2 : x86/x64 MCA ------------------------------------------------------------------------------- Descriptor @ fffffa8005552a08 Section @ fffffa8005552b90 Offset : 664 Length : 264 Flags : 0x00000000 Severity : Fatal Error : BUSLG_GENERIC_ERR_*_TIMEOUT_ERR (Proc 0 Bank 4) Status : 0xfa00000000070f0f 1: kd> !cpuinfo CP F/M/S Manufacturer MHz PRCB Signature MSR 8B Signature Features 1 16,5,3 AuthenticAMD 3013 0000000000000000 203b7dfe It looks like perhaps that is an AMD Athlon II X3 440 Processor perhaps? It's the only thing I can find with that Family, Model, and Stepping for AMD, and it reports as a 3GHz part, but yours reports at 3.13GHz. Anyway, assuming you aren't overclocking, that means it's potentially a RAM or CPU/motherboard issue. It would be best to test your RAM, and assuming that produces no errors on as many passes as possible, you are potentially looking at an overclocking issue or perhaps just a bad CPU or cooling solution. In any case, the hardware is reporting a fatal error, which causes windows to bugcheck (on purpose) to let you know that you have a hardware problem.

Ultimately, you will need the others. There are files and certain IE9 functions that ultimately require those to be installed. IE9 will work, in general, without them, but they are technically required for 100% functionality.

There's no windows file with anything close to that name, so it might help to know what the exact filename is.

You can do basically all of this with the WUA APIs (except scan for patches for another language) - you can use them in script, powershell or C++ or C#. Given that Vista and Win7 are language-neutral, the last one shouldn't be a problem anyway. I've got a few examples in a thread, here. It's vbscript, but it might give you an idea of how to do some of these. JCarle is the WUA API guy here, though, so it might be worth getting him to reply to this thread.

You can inject it, but I wouldn't do it yet (it's still beta, for one). If you slipstream the updates + IE9 you will get a working IE9 slipstream at the end, but it will take time. This is the tradeoff of not having to update an image post-install; those updates still have to finish installing into the image that you've slipstreamed, and it will take time during the actual install. However, I think the IE9 slipstream perf issues might come down to beta and checked code versus retail optimized code.

What modifications have you made to the shell? Those aren't the typical XP shell views, so if this is XP, does this machine have any modifications to the shell that the others would not?

If you installed IE9 beta manually, you'd see it try and download/install these via WindowsUpdate.log or the CBS.log file. However, if you slipstream it, you won't see them installed because the setup engine isn't technically running to fetch the prereq's from the manifest. Hence, the updates are required, but they're not required or even recommended updates otherwise (hence you won't be offered these via WU). You *do* need them for IE9 to work properly on Win7, though, fyi.

Actually, I do not see that these are included in the IE9 beta download itself - if you're slipstreaming IE9 right now, this could be a problem for you above and beyond the slowness, and worth checking to make sure these updates are installed on any Win7 system you might be putting IE9 on via slipstream (and you'd probably want them on there anyway, IE9 or not): KB 2028551 - An update is available that contains improvements to XPS in Windows 7 or in Windows Server 2008 R2 http://support.microsoft.com/kb/2028551 KB 2028560 - An update is available for Windows 7 and for Windows Server 2008 R2 which provides new functionality and performance improvements for the graphics platform http://support.microsoft.com/kb/2028560 KB 2120976 - Streaming issues that are related to Microsoft Media Foundation in Windows 7 http://support.microsoft.com/kb/2120976 KB 2259539 - An update is available that enables the thumbnail controls of certain applications to be displayed correctly on the taskbar in Windows 7 or in Windows Server 2008 R2 http://support.microsoft.com/kb/2259539

Not sure - I've always just followed the deployment guide and it's worked properly. However, you may have to find a way to automate that script if it won't work with your DNS servers properly, which probably isn't that hard to do. Otherwise, you'll have to make sure you specify the KMS host in an msp answer file for Office setup so that it's pre-populated during deployment. Next time, make sure your imaging engineer doesn't even open Office during deployment, as this starts the grace timer (this is is actually something Microsoft specifically mentions NOT to do when deploying Office) .

Considering no such thing has ever existed, it's not surprising you can't find one. Slipstreaming SP3 was supported on the original XP MCE SP1, but not MCE 2005. You will end up with a broken install if you simply slipstream SP3 into MCE 2005, and there are a few other hacks to the installation media that have to be done that are required to get Update Rollup 2 and the cumulative update rollup from October 2006 and still have SP3 install properly slipstreamed (and a few other things related to Media Player as well). Microsoft simply doesn't support anything but installing SP3 over an MCE 2005 SP2 install, so you aren't likely to find an "unaltered" disc in this state at all, because Microsoft never released one. If you want it, you'll have to build it yourself and deal with the mess.

\i386\LANG contains the localized files needed to install language support for regional languages that are available after install, like East-Asian language support. They're not full MUI files, but are needed if you enable the IME language support available out-of-the-box in Regional settings in the control panel. If you don't need any of these other than the language your OS installs with by default, you can whack this folder.

IE9 slipstream is still being worked on, from what I understand, so it's not surprising it's buggy. Anything you slipstream isn't actually finished installing until the image is specialized, so the more that slipstreamed update or software package does, the longer it will take (and the more things you slipstream, the longer this takes too). This is normal, but you might want to post it on connect anyway as a bug to make sure MS is aware of it just in case. Remember IE9 installs 4 or 5 prerequisite patches as well, for what it's worth.

This problem is actually described here, on the Office Deployment Team's blog site, and I found a batch that might help - this should reset your CMID and retry activation with the product key specified against the KMS server specified: @Echo off reg query HKLM\Software\Microsoft\Office\14.0\Common\OSPPRUNONCE if %errorlevel%==1 (goto Activate) else (goto Xit) :Activate C:\Windows\system32\cscript.exe "C:\Program Files\Microsoft Office\Office14\ospp.vbs" /inpkey:<product key here> C:\Windows\system32\cscript.exe "C:\Program Files\Microsoft Office\Office14\ospp.vbs" /sethst:<fqdn of KMS host here> "C:\Program Files\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform\ospprearm.exe" C:\Windows\system32\cscript.exe "C:\Program Files\Microsoft Office\Office14\ospp.vbs" /act REG ADD "HKLM\Software\Microsoft\Office\14.0\Common\OSPPRUNONCE" :Xit Exit Also note your server(s) must be running at least KMS 1.2 for Office 2010 activations to work as well.

Decided to write one to also show updates that are applicable to a Win7 system but are not installed as well, because I ended up needing something like this last night: '// Run with cscript: RunMeWithCScript() '// Connect to the Windows Update COM object: Set objSession = CreateObject("Microsoft.Update.Session") Set objSearcher = objSession.CreateUpdateSearcher Set colSearchResult = objSearcher.Search("IsInstalled=0") '// Loop through and print to screen updates that are not drivers or language packs: For I = 0 To colSearchResult.Updates.Count-1 isLanguagePack = False Set update = colSearchResult.Updates.Item(I) For Each Category In update.Categories categoryID = Category.CategoryID Next If categoryID = "6d76a2a5-81fe-4829-b268-6eb307e40ef3" Then 'Language Pack, print nothing and move to next item ElseIf update.Type = 2 Then 'Driver, print nothing and move to next item Else WScript.Echo "==============================" WScript.Echo update.Title WScript.Echo "" WScript.Echo "Support URL: " & vbCrLf & update.SupportURL WScript.Echo "" For Each KB In update.KBArticleIDs WScript.Echo "KB Article ID: " & vbCrLf & KB Next WScript.Echo "" WScript.Echo "Update Description: " & vbCrLf & update.Description x = 1 For Each strStep in update.UninstallationSteps WScript.Echo x & " -- " & strStep x = x + 1 Next If update.UninstallationNotes = "" Then ' No uninstallation notes, print nothing Else WScript.Echo "" WScript.Echo "Uninstallation notes: " & vbCrLf & update.UninstallationNotes End If WScript.Echo "==============================" WScript.Echo "" WScript.Echo "" End If Next Sub RunMeWithCScript() Dim ScriptEngine, engineFolder, Args, arg, scriptName, argString, scriptCommand ScriptEngine = UCase(Mid(WScript.FullName, InstrRev(WScript.FullName, "\") + 1)) engineFolder = Left(WScript.FullName, InstrRev(WScript.FullName, "\")) argString = "" If ScriptEngine = "WSCRIPT.EXE" Then Dim Shell Set Shell = CreateObject("WScript.Shell") Set Args = WScript.Arguments For Each arg in Args 'loop though argument array as a collection to rebuild argument string If InStr(arg, " ") > 0 Then arg = """" & arg & """" 'If the argument contains a space wrap it in double quotes argString = argString & " " & Arg Next 'Create a persistent command prompt for the cscript output window and call the script with its original arguments scriptCommand = "cmd.exe /k " & engineFolder & "cscript.exe """ & WScript.ScriptFullName & """" & argString Shell.Run scriptCommand, , False WScript.Quit Else Exit Sub 'Already Running with Cscript Exit this Subroutine End If End Sub

Can you save your report and zip/attach it here?

Good luck.

wdf01000.sys is the kernel-mode portion of the Windows Driver Framework, meaning the DPC is coming from a driver that is loaded and using the KDF. From what you've said so far and what the pictures say, we can be sure it's a kernel-mode driver (rather than user mode). We can also be fairly certain it's going to be a network driver, given previous attempts showed ndis.dys (the network driver subsystem) and the current picture seems to indicate netio.sys is probably what's causing the KDF in this case. What network card are you using, and what drivers do you have installed for it?