cluberti

guoqiang, did you not read the post? It said, and I quote, "I do not want to disable it altogether". What you've suggested is just that.

Indeed. You've moved the video from the GPU back onto the CPU, and viola, it's fixed. I'd call either nVidia or the store you bought the card from and get an RMA.

The only way to disable UAC for a program is to go into the shortcut that launches the application's properties, go to the compatibility tab, and check "run as administrator".

Can you upload the files somewhere that doesn't require me to sign up to download the file? Thanks.

Unlike Hiren's, this one appears to go out of it's way to not use warez'ed components. I see a few demos and "for personal use only" tools, but assuming the tool is used as such it's perfectly fine.

The change only takes effect on reboot, so either you hadn't rebooted yet, or it didn't stick. That's the right choice, but that's not the dump type you ended up with after the crash. As to the warranty repair, you can always point to them your dump and state that the other components in the machine test fine, and the machine only crashes when the CPU runs at 100% for a period of time. I wouldn't necessarily offer any more information than you have to, as overclocking may have voided the warranty, I'm not sure. However, if you simply state the facts of the crashing (CPU at 100%, has stock heatsink/fan attached and working properly, all other components have tested out properly under load) without offering what you did before the crash, you'll probably be fine. I doubt they'll ask if you've overclocked it, and there's no "black box" in your CPU that would indicate you've overclocked it, either, so there's no way they'd know if you didn't tell them.

You can't deploy an XP WIM from MDT - MDT's Windows PE is hard-coded to run setup.exe from the install medium to install the WIM, which is how Vista and Win7 are deployed. However, XP doesn't deploy from setup.exe, and as such you'll simply hang when trying to deploy. You will have to use a flat-file install of XP to use MDT to deploy it, or you'll have to create a post-image task sequence and call it after you deploy the XP WIM from WDS.

Well, XP doesn't tax the GPU (even when running full-screen video) as most of the compositing is done on the CPU. Vista does have GPU compositing, but Vista's design actually has a second copy of GPU memory in system RAM, and the compositing of full-screen video, unless the video card driver has hooks to accelerate the MPEG video, would still be done on the CPU. Now with Win7, however, the video *would* be running on the video card directly, even without an accelerated codec, because the screen, in it's entirety, is being drawn by DirectX without any "second copies" when DWM was enabled - this *would* stress the GPU under Windows 7, but not in Vista or XP, on the same exact hardware. I understand you don't see this as a potential cause of the problem, but it's likely because what you visibly see on your computer when playing the flash video full screen (even though visibly the same across 3 OSes) is not actually *happening* the same underneath. I would bet that if you disable aero and force the system to use the standard VGA driver you would see no more lockups (it'd go back to XP/Vista's on the CPU handling the display, rather than offloading to the GPU). If that's the case, you can be sure it's the video card.

That's not a function of the OS though - that's the nVidia driver. You'd have to have an nVidia video card, the control panel + driver, and then it would work. The original question was does *Windows 7* have this functionality, and the answer to that is no.

Well, one of the benefits of a 64bit OS is that you use all 64 registers on the CPU, rather than tying one hand behind it's back by running a 32bit OS (this is the main reason why people report that the 64bit version of an OS feels "snappier" than the 32bit version). And yes, the OS will be able to natively address more than 4GB of RAM, but other than that, the only other obvious benefit would be upgradeability, as Win7 is slated to be the last 32bit client OS from Microsoft. If you wanted to upgrade to Win8 in the future from a Win7 machine, it looks like you'll have to have a 64bit install of Windows 7 to do an actual upgrade of the OS. Other than that, there's not much difference between a 64bit and 32bit OS.

You can also look at %windir%\windowsupdate.log, which should give the error code for the failure.

It seems services.exe is failing to delete or read the following registry key, over, and over, and over,.... you get the picture: Date & Time: 11/19/2009 12:14:57 PM Event Class: Registry Operation: RegOpenKey Result: ACCESS DENIED Path: HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE\0000\LogConf TID: 348 Duration: 0.0000229 Desired Access: Delete Date & Time: 11/19/2009 12:14:57 PM Event Class: Registry Operation: RegDeleteKey Result: CANNOT DELETE Path: HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE\0000 TID: 348 Duration: 0.0000056 Seems like you might want too look at the permissions of the registry keys under \*SMS_MOUSE\ on that machine, as there are literally thousands of these events and this is the only place where the process gets "stuck". Given that the stack is similar to the one you posted above, this is the likely culprit.

Agreed - if IE8's UI hangs totally, that means something's caused thread 0 in the frame proc to pend on something, and if thread 0 in the frame process hangs, the whole UI will hang. If disabling add-ons doesn't resolve it, you can get a hang dump of the iexplore.exe process(es) and upload them somewhere for us to look at.

Unless you need to utilize the other 32 registers on your 64bit CPU, or if you ever plan on upgrading from Win7 to Win8 (or another future version), no. x64 is great and I would never tell anyone NOT to run it, but you need to make sure the apps and drivers for the system in question will run without problems on Win7 x64.

Again, this is only going to affect applications written to use DirectX functions - if an app has no DX drawing functions, it shouldn't do anything to DWM. Here are the Sun Java bugs on this behavior in the JRE, for anyone interested in seeing what kinds of things (however innocuous) can cause it.

Honestly, given a hard hang with no keyboard/mouse input that would likely be some sort of hardware issue, although it's not entirely clear if it's the video card or the system RAM that would be at fault.

This only applies to applications that try to lock the primary display in order to display their own display / windowed settings, and applications written (well) that don't require a display lock will work fine without conflicting with DWM. Applications like the old Macromedia Suite, older versions of the JRE, etc used to do this and as such would disable DWM. MemTurbo obviously does not require a display lock, and thus will work fine without affecting the system. Note that since DWM / Aero are using DirectX for acceleration, and if an app needs to lock DX into a single-use mode, or if an application requires using DX to acquire a display surface lock, DWM is disabled because of a few reasons (including there would be no way to guarantee off-screen compositing will match what's shown on screen with a "locked" app running). Due to the way a screen lock or single-use mode in DirectX is done, and the fact that the Windows desktop *itself* is a Direct3D app, DirectX doesn't have the functionality to allow a full-screen lock and still guarantee both apps will display correctly, and likely never will as the new display model and design allows app vendors to use D3D and not require a lock like this to work properly in Vista or Win7. Basically, the applications that do this are either very old or poorly written, as this shouldn't really be required anymore.

PM sent with upload location.

Well, it looks like you can copy an .exe to a location outside system32 or syswow64 and run it elevated from there, so that would explain the checking not on the WinSxS folder. I'll file the bug, but it's probably "by design". Regardless of whether or not it's a good design, of course .

It's a link to the default 64bit cmd.exe, and yes there is always the hack of using the link to generate the shortcut rather than the executable (it does seem to not check sxs links for "speciality" when you look at the properties, and that's probably a bug ).

Well, it would if you were running IE6. However, as stated, XPSP3 doesn't contain *anything* about IE7 or IE8, therefore it can't fix something it doesn't know about.

No, just the WIM. The XML isn't required (and you probably don't want to automate it anyway above and beyond the .ini files in MDT anyway).

It looks like a device is causing either an insert or remove event, spinning up an interrupt that isn't being handled properly. Do you have the process monitor .pml file to share?

Um.... what does the event log say?

No. In fact, if you create a shortcut to cmd and go to the properties, you'll see you cannot set options on it either as it's a "special" executable in Windows. Running as Administrator is not allowed to be done automatically on certain binaries, and cmd.exe is one of them. You might want to consider doing this instead. No, this is also by design, although the second monitor should go to sleep when the first does (after whatever you have set as the idle timeout in the power config), and if it doesn't that would be a driver problem. From your question, it sounds as if perhaps you skipped Vista. I say this because this was a problem there as well. If an application doesn't support DWM, Aero actually has to be turned off so that the app functions, and DWM is all on or all off, there's no breakdown per-app (currently). It's probably worth filing a design change request for Win8 if it's a big deal for you, but currently this is expected behavior for an app that doesn't support running under theming/DWM.