cluberti

Nothing inside OK, so please download process monitor and get a boot log. Once you reboot, open process monitor and save the log as a .pml file (the default), and then compress it and put it somewhere we can all look at it .

If you look in \Windows\system32\GroupPolicyUsers, do you have any files or folders in there?

As a test, what happens if you were to delete and recreate the remote share, making sure the user has correct permissions to that share folder, and retry?

How are you integrating IE7? What command line are you using to install it?

Yes, I would check for any files that MS08-024 updates (the list is in the KB article) that are not 7.0.5300.13 and delete them from dllcache. Looks like the integration did not replace the files in dllcache, causing the analyze to fail (because 6.0.2900.5512 is technically newer than the IE6 version that ships with the hotfix, 6.0.2900.3314, and since it found 6.0.2900 files it thinks you're running IE6).

So.... basically you're saying you want XP with a window manager.

You need to follow the steps to enable complete dumps of the machine (and reboot) BEFORE the BSOD, otherwise you will get no data.

That is correct, and we have that info posted here as well. Oh, almost forgot, welcome to THE forums !

1st, enable auditing for logon / logoff events, so they'll show up in the security event log 2nd, RENAME AND DISABLE the built-in administrator account - no one should be using this, as this is the most common account for a remote hacker to try and 0wn 3rd, create two new administrative accounts (do not call either account "administrator", and set VERY complex passwords on them so that a dictionary attack takes awhile) - this way you'll not get locked out if one admin account is 0wned, you'll still have a second to use 4th, put a GOOD hardware firewall on the SBS box, or use the ISA server that comes with SBS, and limit remote access to just whatever ports need to be enabled for networked services and VPN Lastly, check those event logs regularly - if you're lucky enough to see it, you will probably see your attacker trying to use the administrator account (which you've disabled), which will generate audit logs in the event logs. This gives you two things - one, it will probably give you his IP address and the time/date he failed to use the account, and two, it buys you time to get the authorities involved whilst he tries to figure out what other admin accounts are on the box. Unfortunately for him/her, it's already too late. You know what IP s/he was using at the time of the attack, and you can find out what ISP the IP address belongs to. As to keeping it from happening, make sure you are FULLY patched before you plug that thing into the 'net, and having a separate firewall (hardware, or a separate ISA server) and router in front of the SBS (rather than using ISA that shipped with it) is usually a much better way to deter things like this. Oh, and once you know what IP address(es) s/he is using, block those on connect at the firewall immediately.

If you have a full dump, put it somewhere we can download it. A STOP 0x8E is going to point to some kernel driver or application that caused an exception that was unhandled (for whatever reason) - any exception in kernel-mode that is unhandled will behave the same as a user-mode exception that is unhandled, the application will crash. Since the "application" in this case is the running kernel, you can imagine that would be bad and cause a bugcheck . Anyway, put the full .dmp file where we can get to it, and maybe we can help. Also note that this is most likely not a hardware problem, but some driver on the system misbehaving. If your memory tested out OK, and your other components are working fine (hardware-wise), then you can pretty safely ignore any potential hardware problems. This bugcheck speaks to a kernel driver, and as such, that'll be where we'll start looking.

Hard to say, but it's usually driver-related. You could use Process Monitor to monitor the boot log and then analyze it once rebooted to see what is happening during boot. Vista also has boot logging you can enable, although I've found that to be less than helpful in most cases (which is why I suggest process monitor instead).

If you slipstream SP0 -> SP3, you will not be able to bypass the product activation screen on non-VL versions of the Windows source. If you slipstream SP1 -> SP3 or SP2 -> SP3, you can bypass the product activation screen on non-VL versions of the Windows source. That's why people slip SP2 before doing SP3.

Someone with a VL version wouldn't need to bypass the product key screen, as they'd have a volume key they could use without activation. The OEMBIOS files aren't in play with a retail or retail OEM copy, only a royalty OEM copy, and those files may or may not get updated by a Service Pack depending on what the OEM manufacturer provided to Microsoft to include. Be disappointed if you'd like, but your point is moot - the original question was about the differences between a retail copy of XP and an MSDN iso - VL was not a part of the question. I answered the question completely, but didn't touch on OEM or VL because that wasn't the question.

I believe these screens are now a part of the winlogon.exe binary, and one would have to edit this binary to change the ctrl+alt+del and "Windows is shutting down" screens.

You need at least version 6.2 to install on Vista, not sure about Server 2008.

RDP server - you can still make RDP connections from the Vista Home install to other machines, but you cannot make RDP connections into the Vista Home install.

Quite astute, as CreateProcess on an x64 OS from a 32bit app will create a 32bit process (in this case, a 32bit cmd prompt) that will have precisely this problem. However, and mritter may already be aware of this, but if the app was compiled to use the Wow64DisableWow64FsRedirection API, this would cause any CreateProcess calls made from the 32bit app after this API was called to start as 64bit processes. You could, as a workaround, use a vbscript instead of a cmd to do your work and use WMI calls to Win32_Processor to determine the processor in the system as well (although it looks like you already have a viable solution).

If the hotfix is included in SP3, then I would think not.

Correct.

Service packs are cumulative. Hence, the Windows binaries that get installed during setup that are updated from SP0 to SP2 will also be updated to the latest versions regardless of whether you go from SP0 to SP3 or from SP1 or SP2 to SP3. However, there is a small difference in the actual setup PID engine in the XP installation routine binaries - if you slipstream SP3 into an SP0 source, you will still be required to enter a product key during Windows setup. If you slipstream SP3 into an SP1 or SP2 source, however, you will have the option to bypass the product key during Windows setup. That's the only difference, during setup - the actual installed Windows product that you would use is exactly the same once setup is finished regardless of what the original source was when SP3 was slipstreamed into the source.

1. Known issue. You have to create an address bar toolbar elsewhere on the desktop, and then move it to the taskbar. This was purposefully done on the later betas and RTMs for some legal reason. 2. Also happens with the RTM version, always good to uninstall. 3. MSN messenger popping up the MSI install dialog means that some portion of the package is not installed correctly anymore, and as such you should either let the repair finish, or, if it finishes but keeps popping up, remove and reinstall the package to correct this. It's telling you that some part of the app is not installed correctly and may be broken. 4. I've never heard of this one, but what happens if you open a command prompt and run "chkdsk /f c:" (you should get a prompt that you'll need to reboot for that to work). Does that run chkdsk after a reboot?

Well, you could take a set of adplus hang dumps of the flashget process while the CPU load is occurring, perhaps one every 30 - 45 seconds (take at least 3) and we can look at the stacks consuming CPU and maybe, maybe learn more.

I have to second what Geek said - you are running the latest (MS08-024) version of IE, it appears, which means the only other way the server would be able to check would be your UA string.

Quite ingenious - viva Italia

Not sure what it means in the context of hfslip, but if it's a windows error dialog the standard error for an 1155 is: ERROR_NO_ASSOCIATION No application is associated with the specified file for this operation.