cluberti

My older AMD Athlon box that I upgraded to Vista from XP does use about the same amount of power regardless of OS. The Vista OS does tax the hardware a bit more, but seems to do better with sleeping when not in use (I use the balanced power scheme). Just saying a CPU at 100% uses more power so Vista must use more power doesn't take into account the overall OS. And if your Vista machine is consistently at 100% CPU, either your hardware is VASTLY underpowered for Vista or you have a problem with your install. This is not normal behavior.

The problem is likely that on the XP machines, something installed on the client is holding handles open to the user's profile and thus it's not unloading properly. Thus, the next load attempt will fail. This is what uphclean was designed to help troubleshoot.

I see from the boot log that it seems to hang when loading the HID (usb) drivers, specifically for the mouse. If you're using a USB keyboard and/or mouse, what happens if you remove those and use PS/2 devices instead?

Since the 69xx and 7xxx builds of Win7 will run just fine on a netbook (usually Intel Atom 1.6GHz w/1GB RAM and a 5400RPM HDD, not even SSD), I would suspect that retail builds of Win7 will run at least as fast as XP, and lighter than Vista (but still use more resources than XP due to additional services and superfetch/readyboost and the like).

Not possible unless you have control over the code - there are ways to make sure memory you allocate are not swapped out, but if you didn't write the app there's no way for you, as a user, to control the memory manager of Windows without completely disabling the swap file.

With my dump analysis above and your thorough memory test, I think it's pretty safe to say that should be enough.

Not only that, but before the FCKGW-xxxx... keys were blacklisted, they were destined for VLK (corporate volume license) keys, not OEM key distribution (royalty or retail). And as someone previous stated, they were blacklisted before XP went SP1, and a quick google search will show that to you. If you get a Windows COA sticker with a VLK blacklisted key, it wasn't legit to begin with (it's a pretty good copy job of the one Microsoft puts on it's website, down to the code sideways on the right, but not entirely close - note the white behind the key, thus not quite good enough). Sorry, you got duped. Thread closed. [Closed].

I forgot I even had it installed, but as I hinted at earlier, this is not a machine I use a lot. But in order to avoid the crap that the people who do use this machine a lot put on here I installed SteadyState. I had no idea that it would override the default Windows Update settings. I have now turned it off and I'm looking forward to seeing if that did the trick. Sorry, I had to chuckle. Did this to myself with an XP system a few years ago. Brings back memories.... lol

@steviewonder: This KB article documents the "rearm patch", as you call it, and it's built-into the OS slmgr.vbs vbscript. This is perfectly legal after the first 60-day eval period (up to 3 times, giving a total of 240 days unactivated) before you can't use it anymore.

I ended up building a 2008 server VM running WDS and MDT 2008 Update 1 to handle these types of build requests (both from my code testing VMs and from family/friends who want their Vista builds done a specific way, usually wiping OEM builds). It took awhile to get all the vbscript scripts and app installs the way I wanted them, but now it's completely automated (minus OS/app patching, I leave that to WU).

Configure your computer for a complete memory dump, and to not automatically reboot. If it's crashing, you'll see it when you wake up - if it really IS running something, you will have to find a way to do some auditing (if you're running business, enterprise, or ultimate you can use local group policy to enable auditing logon/logoff events and process start/stop events into the event log).

Machine_Check_Exceptions do mean something - the hardware encountered an error it couldn't "fix" - knowing what the contents of the MCE error would be great, if you can get it. Sounds like the 32bit subsystem isn't stressing something that the x64 system is, causing the x86 install to run fine (the only thing I could think of would be the extra 32 processor registers that the x64 install would access that the x86 would not, unless you've got more than 4GB of RAM accessing which would be the other "x64-only" feature).

Well, an unclean shutdown during any NTFS flush operation would cause it, so if you had to kill power at a "bad" time that could do it (and since chkdsk cleaned it, that's a very likely scenario).

Well, you aren't likely to enjoy reading this analysis, but... //From the very first dump, I saw something very odd: kd> !thread GetPointerFromAddress: unable to read from 8055fbd4 THREAD 817e26a0 Cid 0158.0184 Teb: 7ffd8000 Win32Thread: e1778be0 RUNNING on processor 0 IRP List: Unable to read nt!_IRP @ 817ece20 Not impersonating GetUlongFromAddress: unable to read from 8055fc6c Owning Process 817afda0 Image: csrss.exe Attached Process N/A Image: N/A ffdf0000: Unable to get shared data Wait Start TickCount 13394 Context Switch Count 5316 LargeStack ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Start Address 0x75b67cdf Stack Init f98a4000 Current f98a39c8 Base f98a4000 Limit f98a0000 Call 0 Priority 15 BasePriority 13 PriorityDecrement 0 DecrementCount 0 ChildEBP RetAddr Args to Child f98a3998 804f170c 00000100 806f02d0 817e2710 hal!KfLowerIrql+0x17 (FPO: [0,0,0]) f98a39d4 804ecae9 00000000 00000000 00000000 nt!KiDeliverApc+0x118 (FPO: [Non-Fpo]) (CONV: stdcall) f98a39ec 804e3b7d 804e3a0d e1778be0 00000000 nt!KiSwapThread+0x64 (FPO: [0,0,0]) (CONV: fastcall) f98a3a24 bf807aec 00000003 817c8af0 00000001 nt!KeWaitForMultipleObjects+0x284 (FPO: [Non-Fpo]) (CONV: stdcall) f98a3a5c bf89b7c4 00000002 817c8af0 bf89e712 win32k!xxxMsgWaitForMultipleObjects+0xb0 (FPO: [Non-Fpo]) (CONV: stdcall) f98a3d30 bf884773 bf9aae80 00000001 f98a3d54 win32k!xxxDesktopThread+0x339 (FPO: [Non-Fpo]) (CONV: stdcall) f98a3d40 bf80110a bf9aae80 f98a3d64 0073fff4 win32k!xxxCreateSystemThreads+0x6a (FPO: [Non-Fpo]) (CONV: stdcall) f98a3d54 804de7ec 00000000 00000022 00000000 win32k!NtUserCallOneParam+0x23 (FPO: [Non-Fpo]) (CONV: stdcall) f98a3d54 7c90e4f4 00000000 00000022 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f98a3d64) WARNING: Frame IP not in any known module. Following frames may be wrong. 00000000 00000000 00000000 00000000 00000000 0x7c90e4f4 kd> r Last set context: eax=00000000 ebx=804e3a0d ecx=804ecae9 edx=f98a3a24 esi=804e3b7d edi=817e26a0 eip=00000001 esp=f98a3a0c ebp=e1778be0 iopl=1 nv up di pl nz ac pe cy cs=3a18 ss=0010 ds=562d es=0000 fs=0000 gs=7c40 efl=bf80101d 3a18:00000001 ?? ??? // Note that the ESP and EBP registers look suspicious - they should be in range of the base limit thread address: Base f98a4000 Limit f98a0000 esp=f98a3a0c ebp=e1778be0 <-!! // A dps to the base address: ... f98a3fc8 8181adf0 f98a3fcc 00000004 f98a3fd0 80562340 nt!ExWorkerQueue+0x80 f98a3fd4 00167398 f98a3fd8 00160168 f98a3fdc 00000000 f98a3fe0 00000000 f98a3fe4 00167398 f98a3fe8 00000040 f98a3fec 001673a0 f98a3ff0 00000000 f98a3ff4 00000000 f98a3ff8 00000000 f98a3ffc 00000000 f98a4000 ???????? <- Base address looks to be corrupt If you've tested the memory, then this indicates a bad CPU or motherboard (or both) - this wouldn't happen if the hardware underneath windows didn't have some issue, and register issues are almost always CPU-related or motherboard-related problems...

This meets the stipulation of the Vista rules. Good info, pinned.

Let's see a dump file to see if there's anything obvious, or if it looks like hardware.

I'll ask again.

Well, considering it's a bug, I'd say call Microsoft. Not much we can do about bugs in Windows code other than try to avoid the codepath, but apparently you are not able to do so. Sorry, but at least the call should be free .

Double-post. Closing this one, reply in the more proper location here.

Do NOT double post.

These are likely DOS-based apps that use VESA resolutions that aren't supported in Windows anymore (this was a common problem when XP released). You will not be able to get these full screen without using a Win9x VM inside XP (maybe under Virtual PC 2007 or VMWare). XP doesn't support odd VESA resolutions like DOS/Win9x did.

All the bugchecks are Stop 0x50's, meaning an invalid memory location was referenced. So, either it is a driver, or you have bad hardware. Would you be able to get a complete memory dump from the box the next time it occurs, and then compress/upload it somewhere so we could look? It'd remove some of the guesswork.

This is Longhorn (Vista/Server 2008) build 4066, from February 26, 2004. This is a build from the codebase before the "reset", meaning it's heart is XP's kernel and code tree, rather than the server 2003 SP1 kernel/code tree that Vista/Server 2008 ultimately was "reset" and built from. Note that Vista and Server 2008 were codenamed "Longhorn" in development. This is a very old Longhorn build, but someone leaked it this month for some reason.

OK, original questions answered. Closing thread before all the feathers get ruffled off. [Closed].

You have to install the desktop experience feature to get Windows Mail.