cluberti

No, that's just the minimum. If it's larger, that's perfectly fine, although from a performance perspective a larger paging file is usually detrimental to overall system performance. Other than the brief times you configure it this large for troubleshooting (when you do want a large paging file to handle the memory being dumped out in the crash dump file), with 8GB of RAM on an x64 Win7 box you probably want a paging file of 1GB or less (most kernel dumps are 400MB or smaller, so 512MB is my usual recommendation). I personally run any machine with more than 4GB of RAM with no paging file at all, and only add one if it becomes an issue with specific software that require one. I've posted on that particular point before.

Actually, these folks are all correct, yet incorrect at the same time. DirectX 9.0c does have a build string of 4.09.0000.0904, and installing the latest update rollup from June doesn't change the fact it's still DirectX 9.0c. What you're looking for once you've installed the rollup are additional files in \system32, above and beyond the base DX9.0c files, like files that start with d3dx(9, 10, or 11)_<number>.dll (there are others, but these are the Direct3D engine updates). You'll note these do have newer values, with (for example) d3dx9_43.dll matching the build number of the latest update. The DirectX End-User Runtimes are an *addition* to the core DirectX binaries, and contain the redistributable feature updates and language translations to the core of DirectX. If a developer actually *needs* these to run his DirectX software, these would be redistributed with the software (or at least you'd hope it would be, given that's the directive from Microsoft to developers on the DX MSDN pages). So while there are some changes in these rollups from the base DX9.0c, these rollups don't actually change the base version of DirectX on the machine - they add to it. That's why the version numbers don't change on the base DirectX files when you install the additional runtimes, and dxdiag and other tools still show the old version numbers.

Visit the link here, scroll down to the section entitled "Memory dump of the entire system", and do steps 2, 3 (3a if necessary), and 4, and then reboot. Ignore steps 1 and 5, as they are not relevant.

ReadyBoost/Superfetch are only designed to improve disk access and optimize file loading. It won't do anything for your memory issues, although it should make booting and accessing files from your hard disk(s) faster. The only way to increase the amount of physical RAM available to the system is to increase the amount of RAM installed in the system. Not sure what training you're talking about, but whatever it was, it was wrong. It might have the side effect that things load faster, but it won't increase RAM storage capacity (and I don't believe you can put the paging file on a removable flash volume either, so that won't help).

Download and extract it from the sysinternals site on Technet here, and then simply execute it. Not entirely certain without seeing the actual crash dump. You'd need a complete system dump of this, as well, not just a small or kernel dump. Windows doesn't necessarily "decide" this at all - it simply detects that a driver has corrupted memory, or caused a page fault in nonpaged pool, or crashes, etc - it then does what it is supposed to do to protect the system, and that is "bugcheck".

Try this vbscript: '// Get an account SID via Win32_Account Option Explicit Dim strComputer, strUser, strSID Dim objWMIService, objShellApp, objItem Dim colItems '// Ensure that cscript is the engine used to run this script: RunMeWithCScript() '// Set error handling: On Error Resume Next strComputer = "." '// Connect to WMI and get the list of Account/SID info: Set objShellApp = CreateObject("WScript.Shell") Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery("Select * from Win32_Account",,48) '// Find the SID for the user: For Each objItem in colItems If objItem.SID = "S-1-5-21-3391303531-2177660944-2853904521-1000" strUser = objItem.Name strSID = objItem.SID End If Next WScript.Echo "SID " & strSID & ":" WScript.Echo strUser On Error GoTo 0 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 If InStr(arg, " ") > 0 Then arg = """" & arg & """" argString = argString & " " & Arg Next scriptCommand = "cmd.exe /k " & engineFolder & "cscript.exe """ & WScript.ScriptFullName & """" & argString Shell.Run scriptCommand, , False WScript.Quit Else Exit Sub End If End Sub

svchost is just a host container for services that don't implement their own service handling (it's also there to save on memory usage). If you run process explorer, you can see which svchost.exe it is, and perhaps even which thread inside of it is consuming the CPU. Remember, an svchost is just a container - it's what is in it that you are interested in.

Drivers sort of, patches yes. The /generalize switch is doing what it sounds like - removing the hardware and machine-specific customizations that were created on the initial install to make the image able to be dropped onto different hardware and work properly. However, there are ways to insert drivers into an image and deploy them as part of the WIM - see this thread (which was 3 posts below yours when I replied) for some possible ways to do this on sysprep'ed Win7 images. I still prefer having drivers injected to the system during the WinPE phase of deployment based on the hardware underneath the current install (ala SCCM 2007 or MDT 2010), but if you know of a specific set of drivers all of your machines will use, adding them to the WIM as per the link above would work fine.

The WAIK includes tools like imagex and dism, and since none of these files are redistributable outside of Microsoft's official WAIK package, you must download and install the WAIK for these programs to be able to use those tools.

Patches will not disappear if you run sysprep.

No, Sysprep does more than just regenerate SIDs, it's useful for generalizing the machine, will allow duplicated machines to work properly with KMS and WSUS servers (and SCCM servers, for that matter, at the very least), and will trigger PnP detection so as to make a more hardware-neutral image. Even if SIDs aren't an issue, you should *still use sysprep* when creating a master image.Also, I would argue that while Symantec Ghost is simple, it is not the best tool for the job anymore. Using even the free Microsoft tools from the WAIK to create a WIM image of the system, along with unicast or multicast deployment from a WDS server, are technically better than using Ghost at this point in time. If you need a solution for more than just imaging and re-deployment, Ghost isn't even the best solution from Symantec for that; Altiris is the product you'd want to look into (it's Ghost+management and deployment tools for SMB to Enterprise). For this user, though, Ghost is probably overkill (not to mention a proprietary image format from a vendor other than the one who makes the OS you're imaging). I would recommend either the OP use the WAIK and WDS, or some of the other open source and freeware previously posted.

If all of the workstations will be using the same BIOS and/or will be the same model, you can probably do this. However, if there are BIOS differences and the SLIC doesn't match the certificate in the OS image, that install won't activate and you'll have to enter the license from the COA sticker on that machine.

Try dir *.iso /s /d - this will give you folder pathing information above the files it finds.

You would need to burn the ISO to a DVD using a disc burning program, or use the Microsoft Windows 7 USB/DVD tool to put the contents on a 4GB USB key.

Agreed - it would likely be an .ISO or a .IMG file, and approximately 3.5GB in size.

Which is why I have a script in my task sequence used to build the machine that gathers the make and model number from WMI, and then only copies the drivers for that device to the system. It takes a little more time to build up the scripts to do this, but it saves on image size and also makes the specialize pass run much faster overall.

Yes, and zune (at least in the US) has an all-you-can-eat plan for $15/mo (and 10 downloads of drm-free songs a month, and you can use it for pretty much any song in the library). Zune + WP7 or ZuneHD really is worlds ahead of the iPod. But, as I said before, with it's already gigantic lead in mindshare and marketshare, people think "iPod" when they think music player, really. It'll take integrated devices like phones to kill it, I think.

Microsoft changed OEM key activations back in the late XP timeframe (but really hit with Vista) - the keys on the stickers attached to OEM machines will not activate online, you MUST call the activation hotline to activate them. It would probably be better for you if you backed up the activation license and key before re-imaging, so as to restore the activation state of the OEM license once installed.

Hope springs eternal .

If your system has Wake On Lan (WOL) capabilities, you can enable it in the BIOS - this keeps the NIC "listening" for a specific packet, and if received, will wake up. However, you may have to do some additional configuration in Windows to get it working.

As to the BSODs with drivers and launching programs, it might be useful to do a reinstall (unfortunately) as your time and effort is probably not worth continuing to track it down (unless it continues after the reinstall). You did originally find some viruses on the machine, and I do have a personal preference that any time a machine has been compromised, you can never really fully trust that install is clean ever again. Normally I don't give up (and I wouldn't, if I had full access to the machine), but in this case it might be worth considering backing up your data and reinstalling Windows clean to at least start from a clean slate.

Agreed - NTFS is fine if you maintain it, just like any other transactional file system. A lot of them have maintenance routines either built into the OS or the filesystem is created in such a way as to try to maintain itself by how it reads and writes (driver), but that takes a huge performance hit on high-volume systems. NTFS walks (very well, I might add) the middle ground of being a very fast filesystem and fairly good at keeping itself from fragmentation. That said, file sizes, NTFS cluster sizes, the MFT, and overall usage patterns will determine how fragmented an NTFS system gets over time. Given the OP said that deleting and moving a large volume of files caused free space to diminish and cause large fragmentation of the filesystem, I'd be looking at the cluster sizes of the filesystem - Dell probably created a file system with either very small (<4k), or very large (>16K+) clusters when creating the image. That would be fine for Windows and program files, but large images and pictures on a drive mean care must be taken to allocate clusters accordingly based on the amount and relative sizes of the data being stored (or planned to be stored), volume/partition size, and filesystem (in this case, NTFS). Most people are oblivious to tuning the NTFS filesystem beforehand to meet the user's needs based on what the drive or partition is planned to be used for, but taking that into account before just creating a drive/partition saves a lot of time and effort on the backend. Just running format or using a 3rd party tool to format with default settings is generally a bad idea (performance-wise) for anything but the OS volume. At this point, it would be easier (and safer) to copy all of the files off to another drive, format the drive, and copy the files back (assuming the OP isn't keeping all of his data on the same drive/partition as the OS).

No, it isn't - hence why I asked. The only thing it could be outside of the machine would be a machine shutdown script or user logoff script coming from AD that hangs it up, but to know that it'd take some troubleshooting with a machine you say you don't have .

Yes, it is designed in Virginia, US, where Invision Power Board Inc is located. And no, this software is definitely fail when it comes to disability browsing, but it is better than the previous version. Baby steps .

Moved - this is a multiboot question, not specifically a PE question. Putting this here for visibility.