cluberti

Is there a specific reason your users need to be Administrators, instead of something like a Power User or a regular User with system modifications to allow them to do whatever it is they need to do, be that registry and/or filesystem changes? Because this is expected behavior when a user is in the Administrators group, and cannot be changed.

Very good. One note - if the debugger is attached to your explorer.exe and doesn't create any dumps, then explorer isn't really crashing. Just a thought...

That's a hard-coded toolbar, so unless someone has a reg hack it's not going anywhere.

You can port most of what you do in a .cmd to vbscript, and if you can't, you can call it directly using objShell.Run or some other such construct. Long term, you have more power and flexibility in a .vbs than you will in a .cmd or .bat file, so at least consider it. You could always call the vbscript from your current .cmd logon script now, though .

Once you've done what I document in getting a dump of explorer.exe, you should have .dmp files in the destination folder. Those can be opened in windbg (make sure you've configured your symbol path) and debugged. If you are not comfortable with that, you can post a link to the files here and we can do it for you. The tools themselves are not going to tell you what happened - you have to figure that out from the data the tool generates .

Ouch - what happens if you install Vista without having XP installed? I'm not familiar with the Vista upgrade discs...

This would be much better handled by vb script: ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // Declare variables, and allocate storage space for them Dim strTestPath Dim intCount Set objFSO = CreateObject("Scripting.FileSystemObject") Set objShell = CreateObject("WScript.Shell") Set objVolatileEnv = objShell.Environment("VOLATILE") ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // Check to see if a UNC path is available when logon script runs ' // Format is strTestPath = "\\server\share" strTestPath = "\\vms\ISOs" intCount = 1 ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // Test on volatile environment variable to avoid running logon script if ' // the user has already run the logon script If Not objVolatileEnv("LogonScript") = "Done" Then Do Until objFSO.FolderExists(strTestPath) ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // Sleep 5 seconds WScript.Sleep 5000 ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // Try connecting to strTestPath twice intCount = intCount + 1 If intCount = 2 Then ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // strTestPath is not available - alert user and exit script MsgBox "Unable to connect to network share for 10 seconds. Please notify your network administrator." Exit Do End If Loop ' // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ' // ' // If able to connect to strTestPath, that means that the server is ' // available, so continue mapping network drives objnet.MapNetworkDrive "Z:", "\\vms\vms" objnet.MapNetworkDrive "Y:", "\\vms\ISOs" End If

Well we know YOU do .

I haven't had to do anything even remotely like that since Win95 - what the heck do you do with your PC to have to reinstall every 8 - 10 weeks?

Moving to more appropriate forum (if there is one) for a request like this.

I'd say install XP Home as clean as you can on your eMachines, and then run the Vista Upgrade Advisor on it first. The Upgrade Advisor will tell you what you need to upgrade, or uninstall and reinstall, before you should attempt to install Vista. Following the Upgrade Advisor's suggestions should keep your Vista upgrade a smooth one. Remember that OEMs like eMachines may have offered the Vista upgrades, but it doesn't mean their XP images were planned to work with it properly .

That you cannot do - setting User Configuration policies on a machine configures it for all users and cannot be broken down in a more granular fashion (some security options can be set for specific users and groups, but that's about it). If you want to target specific users, you either do what you've been doing (edit ntuser.dat), or upgrade to a domain infrastructure.

No, it's a custom 2003 install that is running a custom version of Data Protection Manager - and it's meant only for backup duties and streaming media. It's not meant to be an overall "server", it's a role-based server - a backup and media server. The plan is to sell copies of software to home users, and hopefully home users will find this useful in protecting their data. Obviously it's not meant at the hardcore users, or people who do only email and some basic surfing - it's primarily designed for those inbetween, either SOHO or SMB (smaller than would need an SBS server) to handle backup duties. The streaming media portion of it really pushes it into the retail home user space though, rather than the small SMB market.

You can use Magic Jellybean Keyfinder to find the key you installed with if you're currently running the OS on a machine. If you aren't running the OS or don't have it installed anywhere currently, you can contact Microsoft to request a key. They will likely require proof of ownership, usually a photocopy of the hologram CD media and a proof of purchase other than the COA sticker.

Are you using a .jpg, or a .bmp to set the wallpaper? Also, is the file local or stored on a remote UNC path? This generally only works 100% of the time when you use a .bmp file for the wallpaper, and it's local. Any other combination results in this kind of behavior.

You could put the computer accounts for Vista and XP in separate OUs (based on OS), and create two domain groups - one for Vista users, and one for XP users. Add the users you want to use only Vista machines into the Vista group, and do the same for XP users. Then, in each OS GPO, deny log on locally for each group you want to keep from logging onto a particular OS, and that would do it. Example: Domain | | | - Vista OU | | | | - Vista GPO (deny log on locally for users in the XP users group) | | - XP OU | | | | - XP GPO (deny log on locally for users in the Vista users group) It isn't pretty, but it should work - it'll only allow users in the Vista users group to log on to Vista OU machines, and only users in the XP users group to log on to XP OU machines.

I'm going to build a Business machine from retail media and see if that is expected behavior or not, and then try to "break it" if it isn't .

Only if you needed to uninstall multiple hotfixes in a row affecting said .dll would this be an issue.

There is a limit - I settled on 200 in your case, because that's how many you had. I've seen 173 be the limit on some machines, and I've seen a machine with 317 hotfixes - it depends on the size of the .CAT files for the installed hotfixes. The database containing hotfix info is a jet database, and will ultimately hit a "limit" - it's not hardcoded, but you'll know when you get there, as you won't be able to install or scan for more hotfixes until you uninstall one .

If you want to disable all balloon tips, this worked for XP (haven't tried on Vista yet): Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced Value: EnableBalloonTips Type: REG_DWORD Data: 0

Paint.net, always.

I guess you could call it a bug, but yes, there is a limit to how many hotfixes you can install before this happens (and once you hit the limit, you can't install any new hotfixes, either). Installing a hotfix "resets" this, so when SP3 comes out you would be back to hotfix 0 (with 200 to go).

Hmm... Assuming this wasn't an upgrade to XP, I need to do some research.

Guys - the svchost he's talking about ISN'T THE WINDOWS UPDATE SVCHOST. His best bet is to break out all of the services inside that svchost into their own svchost_<servicename> services and see which one _specifically_ starts chewing up virtual bytes.

- !analyze -v isn't debugging, it's just a jumping-off point. PM me, and I'll give you a location to upload the dump to so I can take a good look at it.