cluberti

You could also use gpedit to remove the ability of all users (other than one admin user you select) to shut down or restart the machine. That would keep those users from rebooting or shutting down the machine, and still allow you to log on as one user and do the reboot.

No, it's likely that the boot data was on the old hdd, and you formatted it away. Boot to the recovery console and run "fixmbr" and "fixboot", and reboot. Should resolve it.

Jcarle is correct - you cannot connect via RDP to an XP Home machine "unsolicited" (i.e. without someone on the Home machine asking you via remote assistance). VNC is a good free alternative.

Those are correct, and should only affect the number of open IE sessions. You can try setting them back to default as a test, but I doubt they'd cause this behavior. I think, at this point, you're probably going to have to go back to a "stock" XP SP2 install, and then add on things from there to see when the problem starts occurring.

Not necessarily, but if you install the User Mode Process Dumper tool and create a rule to monitor dllhost.exe, we can probably analyze the .dmp file that will be created the next time it crashes.

You'll find a wealth of information in the Vista Unattended section of the forums.

The WAIK is for Vista, but you can make .WIM images of XP that you can then dump on machines via ximage. You still need to build a clean XP machine, sysprep it, and shut it down, before you can ximage it (just like Vista). However, it does not recognize or use any of the unattended files created by the WAIK (they're XML, and only used by Vista).

The value is "PagingFiles", and it's in the key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. It's a binary string value, so the easiest thing to do is set it the way you want on a test machine and export the registry key and value. You can then import it to your machine (I import mine during a script that runs via the [setupParams] section of the winnt.sif at T-9) and on reboot, it will have changed.

If it takes the /q switch, it probably will take the "/T:<path> /c" switches to extract it. The resulting installation files will likely give up their secrets with a /? .

Well, x64 by default keeps unsigned drivers from loading, making the system more stable. Patchguard is pretty nice as well.

No, you'll have to add an entry to your DNS server that the client is going to get via DHCP for this server for RIS to work. On a Windows 2000 or 2003 RIS server, option 67 should point to: \OSChooser\i386\startrom.com

I do not see the WeatherStudio toolbar doing anything in this dump other than load, although anything's possible with toolbars. I'll explain a bit on why I believe it's not the WeatherStudio toolbar below. Well, yes, actually, it helps quite a bit. The symbol file errors don't tell me what caused the problem, although they do tell me what was loaded inside the process that the debugger was unable to match to symbols from the Microsoft symbol server (i.e. what 3rd party .dll's are running in the process). Also, dumps are read from the bottom up (the lowest thread is the oldest, and the highest thread is the newest) - and in this case, the thread I see with an open connection pending is running something in "googletoolbar1", or googletoolbar1.dll, and it is in the newest (in this case, also the active) thread, thread 0. Without private (Microsoft internal) symbols for some of these, you don't. And you'll not resolve non-Microsoft symbols (like googletoolbar or weathertoolbar) without adding those yourself, either. This is not a concern. Basically, a WININET!CServerInfo::GetConnection_Fsm call is a chained function for wininet on 2000 SP4 w/IE6 SP1 and XP SP1 (it's a call that actually does 4 functions - these are all documented on MSDN, btw): 1. EnterCriticalSection 2. CServerInfo::KeepAliveWaiters - This is actually two more functions within wininet.dll itself: a. EnterCriticalSection b. LeaveCriticalSection 3. LeaveCriticalSection 4. GetCurrentThreadId What we see, now that we know what that call actually does, is that the googletoolbar1.dll module has actually initiated a connection with a remote server (via wininet, because we're in the IE process space), and we're waiting on it via kernel32. So, either we'll get a response back from the remote server, and the thread will continue, or we'll timeout and the thread will die. There's no way to know if this will be fatal for the IE process or not, but it doesn't matter - there's no reason for a toolbar (or any other add-on) to hold a connection open like this.

Note that there are also applications that require a pagefile to function (take a look at this thread, for example).

If all you're looking to do is reset a password, consider googling for "ntpasswd". IF you actually need admin access from a limited account, look up the sysinternals tool psexec - when you run "psexec -s cmd" from a command prompt, you'll notice the title bar change...

Is that a retail (purchased off of a store shelf) version of XP, or an OEM copy?

28, married, and a son. Married life is good for me, but it's even that much better now with a baby in the house (and double for me 'cause it's a boy!). I guess I'm in the minority here .

That stinks - sorry there's not much more I can tell you. Moving RIS images is a royal PITA - one of the many reasons I no longer suggest riprep images, but automated risetup images (and now, with WDS, WIM images are the way to go).

Option 66 needs to be an FQDN DNS name, IP address usually doesn't work. Option 67 should be set to the boot file for PXEboot, usually "\OSChooser\i386\startrom.com" for RIS or "\Boot\pxeboot.com" for WDS.

I hate to say this, but it sounds like a reinstall of RIS (format of the partition) will be necessary, and those images may be lost.

Uninstall the google toolbar, and the problem will likely go away. It's doing a register server in the registry, and then it looks like it's talking to google's servers, and we are pending the toolbar's response (and it hasn't responded yet). IE traffic will likely fail (and possibly other network traffic on the box as well) until the pending register server request finishes (which it doesn't appear that it will), and thus removal of the toolbar should clear this up. Ultimately a reinstall of the latest version may make the toolbar work properly again.

Have you considered dumping those processes to debug? I can tell you, if it's happening in multiple processes, it's not going to be Vista's fault. If you dump a process while at 100% CPU and send me the dump file, I can probably tell you what you've got installed chewing up the CPU...

Have you tried placing it in the sources folder on the disc, making sure it is named "AutoUnattend.xml"?

The "reinstall once" hubbub was rescinded for RTM - it's basically the same as XP with regards to reinstallation, although reactivation may not work online after one or two retries. YMMV, but from what I understood from the EULA changes, it basically went back to XP's reinstallation/reactivation requirements. And as far as XP support, it goes into extended support in 24 months or so, but it's still supported with an extended support agreement, and security updates will still be released - heck, they're still being released for W2K, as it doesn't officially *end* support until 10 years after it's release, same with XP. It's just that consumer support ends when "extended support" begins, and only customers with SA and an extended support agreement can get non-security change hotfixes from that point on. Security updates continue until the product is 10 years old, and then support for that product drops. For reference, extended support for W2K ends in 2010.

No, it really won't like it. WDS will work fairly well, but RIS has problems. If you're using RIS, your best bet is to install it post-image to the workstation.

Actually, his probably are riprep images, which will show sysprep in the image type. @mcloum: If you remove these copied riprep images, restart the binlsvc service, install from the base XP onto the laptop and image it back, can you see the new image? I've seen this before, where images moved from one server to another do not work once moved, because they were built against a different flat image (amongst other things), and the SCS service links in the images point to files that are different on the new server's flat file, causing the images to not be seen by all machines. In short, you usually have to recreate the images.