cluberti

The flaming will stop, based on rules 7a and 7b of the forum rules. Closed.

Correct - an XP WIM image is an image, just like a ghost image or an image made with any other disk-cloning tool.

I would suggest enabling and logging on with the actual administrator account, and see if that box is actually greyed out. It would seem your bcdedit didn't actually disable DEP for some reason.

Guys, that was awesome!!! I've got some ideas for next year .

Sweet. Chalk another fix up to RTM .

VMWare server will allow you to run x64 VMs on a 32bit host if your processor supports it (there's a machine check utility there on the website, if I remember correctly).

Thanks guys!!! Crahak - I *want* that cake. It's absolutely awesome .

Gotta start at the bottom on this. You probably want a network trace on a slow and a fast machine on the same segment so you can see if it's a delay in the client making a request for data, or slowness in it receiving data.

Win7's kernel will be an updated version of the Vista kernel.

It's a binary text file. Even a 4GB dump shouldn't be more than ~500MB or so zipped.

It's usually a .dmp file in the \Windows directory.

You could install the Microsoft JVM on XP SP0, but it was SP1 that brought about it's demise - if you had it already, you could still install it (and even on SP2, if you had it - it would work), but you could no longer get it from Microsoft.

Well, two problems here. First, since this is only a minidump and we will need to deconstruct the semaphore objects to see why we're in this section of code when a driver caused the crash, you'll need to reconfigure your machine for at least a kernel dump (but a complete dump would be MUCH better) for us to best help you with this. Second, the IRQL that was in use at the time of the crash is 1c, which is the clock level interrupt. Not all STOP 0xA's are hardware problems, but most that are in IRQL 1c actually are - are we sure the RAM in this box is working properly? Again, a 1c 0xA bugcheck can be a driver error, but it usually is a hardware indicator - I'd at least start by checking the RAM. Assuming the RAM checks out with a memory test app (like memtest86), the other vast majority of 1c IRQL bugchecks are video driver or video card related.

It means you had a driver access memory that required a paging operation at DPC dispatch level (IRQL 2) or higher, which is a no-no and causes a bugcheck. Unless you can look at the dump and see which driver is listed as the culprit, you'll need to post it here for us to help. Or, just remove and update all of the drivers in your box .

I like the 11 reference, so I gotta go "one more" there as well: 1. Instant Search (especially Windows Search 4.0 upgrade + sidebar gadget - speed AND control!!!!) - once that index builds, it's fantastic 2. Aero Glass - yay eye candy that doesn't look like lego blocks for a change 3. An OS actually built for x64 natively 4. Dynamic memory management - you won't notice it, but your apps do! 5. The ability to plug in a camera or sd card, and import only the photos changed on that card since the last sync (woohoo!) 6. Superfetch/Readyboost - about time 7. Forcing OEMs to actually ship boxes with 2+GB of RAM finally - it's not 2001 anymore, RAM is cheap - sheesh! 8. Automatic disk defrag out of the box, preconfigured - keep those file systems running smoothly far longer 9. Wireless projector support (awesome if you use it) 10. 2-way firewall protection built-in - again, about time I had protection out of the box! 11. UAC - since Vista Home Premium upgrades for relatives and running low-rights, I haven't gotten calls for machines getting infected with anything malicious (I harped on my family members to PAY ATTENTION before entering in the admin password and clicking "OK" - it worked!!!) 12. Shift-Right-Click giving command prompt and copy path built into the explorer - had to hack to use those before, now they're inbox

The reason AutoIT worked is because copying the file over via the shell into the fonts folder automatically tells explorer to call the APIs to install the font (AddFontResourceEx and CreateScalableFontResource to install the font, and SendMessage with the WM_FONTCHANGE message to all top-level windows on the system), whereas using a manual copy outside of the shell doesn't invoke the APIs and thus a reboot / reload of explorer is required. If you aren't the code writing sort, and you need it to work without a reboot, AutoIT is really your only option.

Well, if a reboot always solves it, then it's likely a driver issue, or a desktop heap resource issue (desktop heap is a memory area in which all GUI objects are drawn and stored, so if you run out you start to get wierd toolbar, icon, button, etc. behavior like this). Also knowing it's x64 and nvidia, I'd go for the former rather than the latter (or the former CAUSING the latter ... ).

Looks like we're all guessing

I've seen a drive catch on fire before, but it had nothing to do with the controller. We did actually remove it from the server and start the platters on fire in a pit.

These are all over the place, would you be able to zip and post the actual .dmp files somewhere?

Log in as the first account he created (should be an admin account as well), and re-enable the administrator account. It is disabled by default once setup is done.

The only caveat is that if you slipstream into an SP0 (RTM, gold, etc) source, you HAVE to enter a product key during install. If you slipstream into an SP1 or SP2 source, you will get the option to not input a product key during setup.

What kinds of things would give you reason to trace such things? Consider xperf from the performance toolkit for this.

Product support services What kinds of problems?

Note that nuhi has many times over posted that if you use vLite to modify and strip anything from RTM, SP1 will not install (or will not install properly). The best (and maybe only) thing to do is back up your data, re-run vLite against your install source (using it to modify your Vista source and slipstream SP1) and reinstall.