cluberti

Well, they're not exactly the same drivers, because you don't use 32bit drivers on 64bit Windows, but I understand your point. If you can get the setup*.log files from C:\Windows, that might be helpful.

It's a warez release of Windows 7 - steer clear.

#1 - disable UAC in the control panel while we're troubleshooting (as long as you know your computer is clean, of course - don't want to give any malware or viruses a chance to get worse). Then, gather a trace using xperf and post the contents back (as per that thread). #2 - Again, even though you're in the Administrators group, you have a filtered token (by default) and you're also not using the local Administrator account (this account is disabled and hidden unless you're in safe mode). You need to go to the permissions of the folder or file, click the Security tab, click the Advanced button, and then click the Owner tab. If you're not the owner, take ownership by clicking the Edit button and selecting your account from the list, click OK (you have to close the properties dialog - you'll get a message pop up telling you so), then go back into the properties of the folder, click the Security tab, click Advanced, click Change Permissions, and add (or edit) your account to have full control (all allow permissions). Make sure the checkbox for "Replace all child object permissions..." is checked, then click OK. You should now be the owner of the folder itself, and any files inside, and have full rights to all of them, including the ability to delete them.

Add @echo off at the top.

Well, it could be anything - I doubt it's Windows itself, but I wanted to know what was on the media (apps, drivers, etc) and see if one of those could be the culprit. I've never seen Windows itself do that without some coaxing.

Were there any customizations made to the installation media (driver injection, service packs, etc)? Is this the same install media that was used to install the machine before, when it was working?

Frankly, if you're running as an admin and/or have disabled UAC, 7 and Vista have basically the same security model. I've been taking this thing apart to see how it works, and you are most definitely NOT more secure on Vista when it comes to this particular one. This one appears, from disassembling it, to be a variant of the other Worm.MSIL network worms (like the PC security scam malware). The processes it spawns appear to be looking for email programs and network ports to try and replicate itself. On Vista or Win7, if you run as admin or do not run a browser that runs as a low-integrity process (like IE or Google Chrome) and come across a site that is dropping this particular malware, it will infect Vista or Win7. If you open a .zip or .rar file that contains this and execute it's contents, it'll infect Vista or Win7. If you disable the host's firewall and are running as administrator at the time, you can get infected if the binary is executed after being dropped. None of these things will be protected in any better way on Vista than they are on Windows 7.

Why not use ADMT?

Service packs cannot be applied offline like other updates, so if you're talking about putting the Service Pack in the Packages folder, no. However, if you're talking about deploying it online with your task sequence after your image has been applied and booted, then yes.

I think we have terminology conflicts here - sysprep does it's thing when you run it. After the reboot (or when restoring the image to another machine), setup is going back and specializing the machine (because you /generalize'd it with sysprep). Does this occur if you install Win7 on your hardware from media, add no apps or additional drivers, and then sysprep/restore it? I'm trying to figure out specifically whether or not it's the hardware/drivers or something you may have installed into the image that's causing an issue.

Actually, are you sure about that? What is does show us is sysprep took about 2 minutes, and half of that was reflecting drivers:2010-07-21 21:45:15, Info SYSPRP SPPNP: Reflected all boot critical driver packages (61153 ms). If the OP is saying that sysprep is taking 60 minutes, and the log shows 2, we need him to actually get out his watch and note the time he presses enter after sysprep /generalize /oobe, and the time the box shuts down. Then, we compare that to the sysprep log to see where in that time sysprep actually runs, and finishes. My guess is sysprep runs at the END of the time the OP is stating, rather than the beginning, given that sysprep is shutting down the system (and I think the OP would recognize if shutdown was taking a long time versus sysprep). That would mean, at least empirically, that after the OP runs sysprep /generalize /oobe, it takes upwards of 57 minutes for sysprep to actually start - hence, PROCMON . Something's fishy, and given how long the boot critical driver reflection is even during the 2ish sysprep minutes of the panther log, I'm wondering if Defender, or an Antivirus product, or some other boot driver is hanging up actually running sysprep, or if he's got an unhealthily large registry...

I would question the benefits of this. The OS itself isn't threadsafe, so you'd have to split the OS functions on one core or the other and handle IPC yourself in a driver - the OS would still be single core, and you'd have some overhead in IPC for an OS that expects everything to be serial. You could do a base split (like rloew's post on DOS previously), but to *really* split the OS, you'd have to either rewrite large parts of the kernel or do all the IPC in your own driver, and I'm actually not sure which would be harder (and that's not sarcasm). On top of that, given there are no apps I am aware of that actually support 9x and have any sort of multicore support for that OS, there would be very little benefit. People with really slow machines might, but even a PPro 200 is fast for running 9x, so a modern(ish) multi-core or multi-threaded CPU really isn't going to give you a whole lot of noticeable benefit to using multiple cores under that OS. If you want an older OS that's multi-core capable and will run on older and newer hardware, honestly, using a BSD or Linux would be a better choice.

The sysprep.inf autologon is only going to attempt to auto logon with the local Administrator account, none else. If you need this machine to auto logon with a different account, you're going to need to add that to the winlogon registry and configure autologon that way instead (you can probably add the reg necessary for this from a script run from UserExecute in SetupParams).

So you opened windbg, clicked file > open crash dump, pointed it to the .dmp, and it opened fine?

Using MDT 2010 for XP deployment is fairly simple, and not really different from deploying any other OS. Also, deploying Windows XP with a default key (based on the type of install - retail is what you're using, I'd guess, if you're talking about a key per install) or no key at all isn't necessarily difficult either via MDT. The last reason I'd suggest MDT is because you can use WDS to deploy (by putting the .wim it creates on the WDS server), but you can also create offline media of the same exact deployment share as well, so if you ultimately don't have WDS, you won't have to redo anything to deploy with removable media.

Supposedly the .dmp file is corrupt - can you open it with windbg on your machine to make sure it's actually valid?

Windows 7 doesn't allow ICMP through the firewall by default, so ping would indeed fail. However, you should be able to go to \\win7 and view any public shares that are available - if not, try disabling the Win7 firewall to see if it magically works (it probably will if you get to that point), and if so, you'll have to tweak the firewall rules on the Win7 box to allow the traffic you want on the network profile it's using for that network.

Doh! Oh well, can't always type what my mind is thinking . True, although I'm pretty sure this user's ISP is not one of those.

Being behind a router, and not directly connected, *does* indeed increase the risk of infection, BY FAR. If you're trying to get infected, then this would most definitely be a bad idea, hence why the suggestion was to use no firewall, no router, and connect an XP RTM or SP1 box directly to the internet. That'll get you infected, probably within a few minutes, with all kinds of nastiness.

I don't think this one's gonna be possible from vbscript, but it might from powershell. It would also work from a C++ or C#/.NET app, of course.

Seconded - if this is an XP machine, just install it (preferably SP1 or RTM, as they're more vulnerable out of the box) and attach it to the internet with no protection (also second settup up a bogus mail account). Especially if you're on a shared broadband network like cable, your machine will get dirty, and quickly.

I agree it won't, but not because consumers will stop buying every new version of every new product from Apple. They'll stop because competition will catch up with them (the iPhone is the king, but it's not necessarily the best device or OS). However, given they're in such a huge lead in an area (consumer devices) where they're re-purchased every 2 - 3 years in major markets, they'll still have sales growth from those devices - if they have to price down to compete, however, that might not be good for their overall profit and margins.

Or use your own custom WinPE image (or something like MDT). Or just leave it out of your unattend, and force setup to prompt.

You don't need either for getting a system crash dump. As to the packages, the old ones still work (and are a much smaller download), so until MS pulls them or they stop working on newer OSes, I'm still suggesting they be used over the ones in the WDK unless you've already downloaded the WDK for other reasons.

Bad drivers would not cause a BIOS error, no.