cluberti

Well, I'm not sure why you wouldn't install Vista again, as IE8 will install on Vista (unless I'm missing something that's less than obvious here). But, with regards to CBS vs update.exe, update.exe has been around since the Win9x days, and is really limited in what it can do during install (both online and offline) with Vista and subsequent Windows versions. I really don't know what the complaint is here, but perhaps I'm missing something.

When you use the search fields in Vista (either in the start menu or in the search box in an Explorer window) you are searching for file names, keywords, or text within a file (those are the default parameters). Also, Vista searches all of the "indexed" locations, and omits others unless you do an advanced search and explicitly search non-indexed locations. You can change this behavior from the Indexing options in the control panel.

If you can configure your machine for a complete dump, and then recreate the crash and upload the resulting memory.dmp to a fileshare somewhere, perhaps we can take a look at it.

Right, because the underlying engine required to do so is only on Vista, not XP (update.exe on XP vs CBS on Vista).

That's the main engine for the Java Runtime. If you uninstall java from the programs applet in control panel, you should be able to get rid of that. If you need java, a reinstall should work of the latest runtime (which I believe is 1.6 R11).

I know this is hardware, but I'm moving this to the 9x section so that the folks there can have a crack at this particular issue.

All the time. It's why you pay for premier support, and perhaps third tier. If you use your support wisely, it's worth every penny.

That doesn't change the supportability matrix. Microsoft *will* release security updates until extended support ends in 2014, but there are no more bug fixes outside of mainstream support unless you have a premier contract, custom support agreement, and extended hotfix support agreement with Microsoft for a product past mainstream support (and that's not a guarantee that a bug will get fixed, either, just a guarantee that they'll look into it). When mainstream support ends, you also lose the ability to create free support cases (unless the problem is caused by an update released after mainstream support ends, and you can prove that said update caused the problem you open the case for).

For personal usage, I had a regular old cell for years and it was fine and I had no issues (only using my smartphone for work). I finally bit the bullet and got an HTC Touch Pro on my last phone upgrade for personal use, as I find myself nowhere near my personal computer more and more often, and traditional phone calls are not the main way I keep up with family and friends any longer - it's now IM and email due to travel, time zone differences, etc. I must say, the HTC has quite good battery life once I sprung for the 2000mA extended life battery, which gives me about 16-24 hours of moderate usage before I have to recharge. On the standard battery it was 8 hours of moderate use, although I can get the phone to last about 3 days if I try to stay off the internet and check mail manually (which I'm starting to get used to doing).

Yes, I repro'd it on 5 machines across multiple aero-capable chipsets, so it seems like a DWM problem and not a video driver issue.

Not sure of a solution, because it looks like a problem with DWM, but I would suggest using send feedback links to file a bug, as this is definitely a bug.

It's not just the size of the disk, it's the type of disk and the speed. Lots of people go from 3 to 5.x or even 6.x numbers when disabling write caching, so if you don't get that big a bump you just simply have a slow hard disk.

Usually a stop 0x50 is a page fault in nonpaged pool, and if disk.sys is doing it I'd be very suspect of anything hooking hard disk access or potentially faulty disk drivers or the underlying disk hardware itself. Have you tested your disks to make sure they're OK? I'd start there, then I'd move up the chain and make sure the disk drivers / chipset drivers themselves are of the latest version, and then I'd make sure it wasn't your antivirus package, in that order.

Really? Are you sure that the dates for XP x86 and XP x64 aren't identical? The mainstream and extended support dates look the same to me.

No worries. Glad to have you onboard.

It looks like the Outpost firewall driver is crashing your system: 0: kd> k ChildEBP RetAddr b8877bb4 806644a2 hal!KeAcquireInStackQueuedSpinLock+0x26 b8877bd4 f5374131 nt!VfIrpDatabaseEntryReleaseLock+0xae WARNING: Stack unwind information not available. Following frames may be wrong. b8877be4 f53636c0 afwcore+0x12131 b8877c04 f5363cd6 afwcore+0x16c0 b8877c1c 804ef19f afwcore+0x1cd6 b8877c2c 80658128 nt!IopfCallDriver+0x31 b8877c50 8057f982 nt!IovCallDriver+0xa0 b8877c64 805807f7 nt!IopSynchronousServiceTail+0x70 b8877d00 80579274 nt!IopXxxControlFile+0x5c5 b8877d34 8054162c nt!NtDeviceIoControlFile+0x2a b8877d34 7c8fe4f4 nt!KiFastCallEntry+0xfc 042bf914 00000000 0x7c8fe4f4 0: kd> .bugcheck Bugcheck code 1000000A Arguments 0000001c 00000002 00000001 806e6a16 In a stop 0x1A or 0xA, the first parameter is the memory address referenced - in this case, it's 0x0000001c. Since the first 64K of VA for any process is marked as PAGE_NO_ACCESS, and 0x0000001c would fall into said 64K, this access is going to fail. Worse, because the second parameter is the IRQ Level at the time of the dump, and the machine is at IRQL2 (dispatch), any page fault or memory access error at this IRQL or higher is actually *supposed* to cause a bugcheck, because otherwise the system could conceivably get stuck in a dispatch loop and do a hard hang at this point. Also, note that the EIP register is invalid here as well, and EIP is the CPU register that tells the CPU what instruction to execute next. Since this is invalid, bad things are going to happen - ultimately, this is what started the whole mess: 0: kd> kv ChildEBP RetAddr Args to Child b8877bb4 806644a2 83235f98 f7aaa870 f7aaa890 hal!KeAcquireInStackQueuedSpinLock+0x26 (FPO: [0,1,0]) b8877bd4 f5374131 8394a6c0 f53740da b8877c04 nt!VfIrpDatabaseEntryReleaseLock+0xae (FPO: [Non-Fpo]) (CONV: fastcall) WARNING: Stack unwind information not available. Following frames may be wrong. b8877be4 f53636c0 8598bbe8 8394a6c0 8598bbe8 afwcore+0x12131 b8877c04 f5363cd6 8598bbe8 8394a6c0 8598bbe8 afwcore+0x16c0 b8877c1c 804ef19f 8598bbe8 8394a6c0 806e6428 afwcore+0x1cd6 b8877c2c 80658128 854b23a0 806e6410 8394a6c0 nt!IopfCallDriver+0x31 (FPO: [0,0,0]) (CONV: fastcall) b8877c50 8057f982 8394a730 854b23a0 8394a6c0 nt!IovCallDriver+0xa0 (FPO: [Non-Fpo]) (CONV: fastcall) b8877c64 805807f7 8598bbe8 8394a6c0 854b23a0 nt!IopSynchronousServiceTail+0x70 (FPO: [Non-Fpo]) (CONV: stdcall) b8877d00 80579274 000001d0 000005a8 00000000 nt!IopXxxControlFile+0x5c5 (FPO: [Non-Fpo]) (CONV: stdcall) b8877d34 8054162c 000001d0 000005a8 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) (CONV: stdcall) b8877d34 7c8fe4f4 000001d0 000005a8 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b8877d64) 042bf914 00000000 00000000 00000000 00000000 0x7c8fe4f4 0: kd> .trap b8877d64 ErrCode = 00000000 eax=00185d98 ebx=00000000 ecx=7c82ff82 edx=7ffab000 esi=042bf964 edi=00000000 eip=7c8fe4f4 esp=042bf8b4 ebp=042bf914 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 001b:7c8fe4f4 ?? ??? 0: kd> dc eip L1 7c8fe4f4 ???????? ???? With all that said, the machine crashed because the kernel-mode driver afwcore, running inside process acs.exe, caused a memory fault at DPC dispatch level, thus the machine bugchecks. All 3 dumps are the same, meaning that the crashes appear random, but are not. I believe acs.exe and afwcore.sys are a part of the Outpost Firewall, so upgrading that may help - here is the current version: 0: kd> lmvm afwcore start end module name f5362000 f5399a80 afwcore T (no symbols) Loaded symbol image file: afwcore.sys Image path: afwcore.sys Image name: afwcore.sys Timestamp: Mon Jun 30 09:16:08 2008 (4868DC98) CheckSum: 0003CC9D ImageSize: 00037A80 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Note that if the problem exists in any newer version, upgrading obviously isn't going to resolve the problem, and your only real recourse is to uninstall the Outpost firewall and file a bug with the vendor to have this fixed. Good luck.

%windir%\memory.dmp is where it's located on your system.

Well, I had a similar problem, but it also caused my machine not to be able to go to sleep. I had a Microsoft mouse, and I didn't have the latest IntelliPoint software installed. Until I did that, I would get random usbport crashes and hangs, and when it would actually work, the machine would not go to sleep. Ever since updating with IntelliPoint, the problem has gone away. So, if you have a keyboard or mouse (or any other USB device attached to the PC) that comes with driver software, you should consider installing the latest version of said software/drivers to see if it fixes it.

Note I was speaking about "the list", not this specific update. QFE's are indeed not public nor available on WU (unless we're talking about IE updates, in which case these are on WU but you won't be on QFE unless you do it manually once... I digress). I am aware of this - again, not speaking of this specific update particularly. I know the history behind this particular update intimately. And in this you are correct. My mistake.

If you don't like the fact that a security update is not on WU for a specific platform, consider harassing Microsoft about it. If no one complains, it won't change. I agree, this should probably be on WU for W2K, XP, and 2K3 systems as well as Vista/2008, and although it does require a reg change to make it effective it still seems like it should be public.

The recovery console is documented here. I would suggest using "help disable" to learn about how to disable services or drivers.

Without an XP disc so you can get to the recovery console and disable the volume snapshot service, you're pretty much up a creek if you can't boot into safe mode or last known good. Either you need to disable the service from the recovery console or a recovery disc, or you need to boot to last known good (and that may, or may not work - but you should try). Do you know if anything was changed/added/etc before it was last shut down, perchance?

No, not external removable, *internal* - like this one for instance. But good to hear you got them back in the correct order. I'd still suggest a removable hard drive tray .

The only thing that SPs did to the product key is keep adding new checks for pirated keys with each version. Valid keys from RTM (SP0) still work with SP3 discs - the only other thing that could cause it is if the disc is a royalty Dell OEM disc (usually purple or blue sticker with "Dell" on it, not a hologram CD) and your key is for another type (retail OEM, retail, corp, etc), or the converse, etc. I'm guessing your XP Home OEM disc isn't a Dell disc (as you say yourself you don't have a DELL disc, you have an XP Home OEM disc), and thus from this I can infer that it's very likely your XP Home CD is a real OEM XP hologram disc - meaning it's OEM, but it is a retail OEM, not royalty OEM disc, and a royalty OEM key will absolutely not work with a retail OEM CD without hackery to the CD. Just because it's an OEM disc doesn't mean it'll accept just any OEM key.

Note that these are indeed "hotfixes", QFE fixes that are relatively untested compared to the regular updates from WU. Installing these is up to you (and you can find most of them on the microsoft.com site, they're all KB'ed), but it might make your install do things you may not want due to potential bugs that won't be found until people use these outside the environment / customer they were written for....