cluberti

shlwapi.dll is the Shell Lightweight API library, and is used by the Windows Shell (explorer.exe) and Internet Explorer. SHLWAPI provides many shell related APIs for the operating system to use - these functions include string manipulation, URL parsing, association determination, path information, and registry manipulation (there are more, but a user wouldn't run into these specialized API's without some dev experience). If you delete shlwapi.dll, you will find certain functions of the shell will stop working as well.

Fine by me. I still stand by my claims, but I feel you probably do too - I think we'll have to agree to disagree on this. Edit: slightly OT - did you know there's a KB article that goes along with the link in your sig? http://support.microsoft.com/kb/555375

Do you have SBS2003 SP1 installed on this system?

I would strongly suggest doing sfc /scannow from the command prompt, and if that doesn't work, do a repair installation. If the steps in the KB article didn't work, you likely have modified or corrupt (or at this point, missing) system files relating to the Windows Installer engine.

I don't have anything public on Microsoft's site that I can point you to, as I only have internal PSS support incident cases that contain this data. No antivirus vendor is going to publish issues like this on it's website, either. You can call me out all you'd like, but I'm not sidestepping the issue. I'd like to produce data to back up my position, but I'd likely be let go for doing so, and I'd rather not. You can believe me, you can not believe me - it really doesn't matter to me, and changes my opinion of NOD32 not a bit. I believe it to be a program that uses far too much kernel memory resources, and I've seen data with my own eyes attesting to the problems it can cause (and it's not alone - most A/V packages use far too much kernel resources when in use). Again, believe me or don't believe me, it's your choice. Use NOD32 if you like it as well, I'm not here to advocate one product over another - they're all equally bad.

It's quite easy, actually. Start > Run > gpedit.msc > User Configuration > Windows Settings > Scripts (Logon/Logoff).

Is the service not listed in the services control panel applet? What exactly did you do in your troubleshooting?

gprefresh was an XP-only tool - 2000 used secedit. However, I've not found gprefresh on any of my XP machines, and I don't see it on an XP gold machine either. It perhaps didn't make it out of the beta/rc stage and into the final product? I can't find any documentation either way, but I can say for sure that I do not see it on an XP RTM build, nor on an SP2 build - only gpupdate.

MCE 2005 is only supported on Windows XP 32 bit. Go to your System Properties (Start > Control Panel > System) and see what it says under "System". If it's 64bit, it'll say so. Otherwise, it'll probably say Windows XP Professional Service Pack 2, which will be 32bit.

All I can say is that I work for Microsoft, in Core OS support, and have for many years. Past that, I can't put case information on the 'net - suffice to say, almost ALL A/V products all have issues (although I'd say McAfee was the worst) with using more than their fair share of kernel memory resources, and NOD32 is no different. And rarely do I blow anything up anyone's USB ports, short of compressed air when cleaning the innards of a PC. It's great that you have had no problems, but you not having problems doesn't mean others do not or will not. Again, 64bit Windows alleviates some of the kernel memory resource issues, but not all.

It has EVERYTHING to do with the hang - if Windows can't unload the registry, it WON'T shut down for fear of corrupting it. Have you installed any antivirus software, antispyware software, or printer drivers recently that may coincide with the problem's first occurrance? These are the usual suspects. Also, you may want to post this in Windows XP - if you truly have Windows Media Center Edition 2005 installed, it's only 32bit...

With that many machines, you may want to consider SMS for this type of duty...

Not sure about gprefresh... I wasn't aware it was included in XP.

As Minus previously stated, you can check the Windowsupdate.log file on the server you believe to be having the issue to see the log of AU traffic on the server in question - there's likely errors being logged there.

I think the error already answers your question.

Sorry - this is a bit beyond the scope of group policy.

You will likely need a dedicated hardware device (preferrably the router) that provides bandwidth provisioning and has QoS capabilities, or install a firewall that has these capabilities. Neither of these options will be cheap, unfortunately. You have good intentions, but you're talking about doing some serious traffic shaping and QoS on a per user (or per IP) basis, which requires a very smart device. It might seem simple in theory, but in practice this is not something that is done easily.

You could add a variable to the OSCHOOSER which requires user input, and use that variable for creating the machine name.

The "internal name" of the hal.dll file will tell us what XP determined the BIOS to be able to support - assuming the internal name isn't one of the hal*acpi.dll variants, then it's a BIOS problem. If the internal name IS a variant of hal*acpi.dll, then it's a Windows problem. I was trying to narrow it down.

This is another one of those "designed for Windows 98" hardware devices that may, or may not, work under XP x64. You'll have to try drivers built into the OS for this, and hope one of them works; this is going to be lots of trial and error, with no guarantee that any inbox driver will work.

That card isn't technically supported under Windows x64, but the generic Soundblaster 64 driver may (or may not) work - I've seen both. The card you speak of was designed for Windows 98 - so don't be surprised if it doesn't. There are no native drivers for it, and you can bet that they won't be forthcoming from Creative.

If you have all of the latest drivers installed for everything on your PC (including the chipset), then I'm not sure where that's coming from. It seems like it could be a driver issue, unfortunately, and given the history of this post, it's probably a chipset or drive controller driver that's at fault here.

It sounds like XP installed itself as "Standard PC" rather than an ACPI version - could you go into the properties of hal.dll in C:\Windows\system32, and tell us what version your "File Version" is, as well as the "internal name"? Both of these can be found on the "Version" tab in the properties of the file.

Cool.

http://www.sysinternals.com/Utilities/NtfsDos.html or, even better: http://www.winternals.com/Products/Adminis...ak/Default.aspx