cluberti

Yeah, you free up RAM, but you're just flushing part of the process to disk - you don't actually reduce the memory usage of the process, just the RAM footprint. If you (or the system) go to load a process again, the necessary bits go back into RAM. Not a bad idea, but may not be as useful as you'd like on a busy system.

Well, could you run dependancy walker against explorer.exe and post all of the files explorer.exe loads? http://www.dependencywalker.com/

http://blogs.msdn.com/mssmallbiz/archive/2.../07/461961.aspx

The "Click Here" links only show the module faulting - it doesn't give stack information in case we need to walk back to find the first-chance or the failed call. The module in the links is usually a victim, rather than a cause. So yes, Dr. Watson should be checked, just in case.

No, I'm pretty sure the Windows Update and Microsoft Update sites change whole class C ranges quite often, so unless you plan on allowing a whole class B range of IP's, I'd say you may be out of luck. Perhaps someone else with KPF has run across this little issue? Have you googled this yet? Also, I am pretty sure that the latest 4.x versions support dns names, but I could be wrong. I haven't used a software firewall other than the built-in Windows firewall in quite some time. Sorry I can't be more of service.

Is the folder in the Startup folder of the Start Menu? If not, download Autoruns from http://www.sysinternals.com and see what's starting when your Admin user logs in - could be a startup item (most likely is).

Well, the error tells you what's wrong - open services.msc, and start the "Security Center" service. If it won't start, check the event logs for details on why.

Well, there are two differences, actually, and they matter quite a bit. 1. The OEM version comes with no support from Microsoft in any way, short of public hotfixes and service packs. If you need a private hotfix or other support, you'll pay $250 per incident if you contact Microsoft. OEM copies are meant to be supported by the company or system builder that provided you with the PC that the OEM version of Windows is installed on, not Microsoft. 2. The OEM version is technically only allowed to be sold with new hardware, and since September 2005 that doesn't mean a power cord or memory stick, it means a whole new PC. Otherwise, you may not fall within legal boundaries for buying OEM copies. Now, if you're an OEM system builder recognized by Microsoft, you can do this, but the copies cannot be for your own personal use on a pre-existing PC - they are to be given to purchasers of your computer systems (hence, system builder), or to be installed by you on your own new PC (which you will support). So, the price is actually the least of the differences.

I hate to state the obvious, but doing things like this is very well documented on this very site: http://unattended.msfn.org/

Have you tried extracting the driver, and then updating it manually by pointing the driver update manager at the source?

Sounds like you've got a corrupt download - the error is usually the cause of a damaged file header (this is likely the case if you don't have every last bit of the original file, and then try to execute it). The shell manager reads the file header (this time of type "executable), and thus passes it off to the memory manager to load it into memory for use. However, since the header is likely corrupted, the file's beginning (or end) information cannot be read by the memory manager. It assumes that the file is too big to load into memory (it has a beginning, but likely no end - a fair assumption, actually, but leads to an erroneous error message), and gives this error. To make a long post longer, re-download the file again. If you're using a proxy to access the internet, use a download manager, or, get the file from a source that has verified the MD5 sum of the file (so you can check yours against the master after downloading). There are other ways to make sure the file is legit, too, but these are the most obvious.

Wise choice .

Are you integrating this from the command line using the /integrate switch, or nLite / HFSLIP / etc to do so?

Are you certain that the GPO object isn't configured to have the computer configuration disabled? Also, did you use the Group Policy Management Console to edit the GPO, or did you do it from AD Users & Computers?

What exactly are the explorer errors? And do you have Dr. Watson complete dumps of the process crashing? Run drwtsn32 from the command prompt and configure it for a full memory dump, and the next time explorer crashes it should create a complete Dr. Watson dump in the path specified - post that here (or email it to me) and I'll tell you what's crashing explorer.exe.

I'm not getting involved in page file size issues, as there are as many right answers as there are wrong. However, this statement by nmX is not correct: You need to use the /PAE switch, not the /3GB switch, to enable page file sizes larger than 4GB (with /PAE enabled, you can make 16TB page files).However, I strongly suggest NOT using the /3GB switch on ANY machines that do not have processes that need to address more than 2GB of virtual address space. The /3GB switch does NOT have any connotation to actual RAM usage, but to VIRTUAL ADDRESS SPACE usage. This shoves the kernel resources into 1GB of VIRTUAL ADDRESS SPACE, and reduces the nonpaged pool to 128MB (instead of 256MB), the paged pool to 160 - 230MB (rather than 350 - 560MB), and reduces the number of free System Page Table Entries (PTE's) from ~200,000 to 40,000 (or less). All of these things can and do hinder system performance, especially the low nonpaged pool and PTEs - and even more so if you have a higher-end video card (those things eat PTE's for breakfast). So, check the Virtual Bytes and Private Bytes counters for each instance under the Process object in perfmon - unless you see one process (and not the _Total process) using close to 2GB, DO NOT enable /3GB. As to /PAE, it's really only useful if you're running Windows 2000 Advanced or Datacenter Server, or Windows Server 2003 Enterprise or Datacenter Edition - these are the only Windows operating systems that can address more that 4GB of RAM. There are some memory issues when using the /PAE switch too, so be sure ALL of your drivers support running in AWE mode, or you'll have problems.

Are they public, or private hotfixes? You can probably see where I'm going here...

I'm not sure there's a technical problem here. You're using the [GuiRunOnce] section to run your .cmd file, that enters your registry settings for doing the RunOnce installation. If what you are saying is correct (it takes a second reboot to get the apps to start installing), this is expected behavior. From the description of GuiRunOnce in the Windows 2000 Resource Kit: So, after your setup finishes, your computer is logged on, the .cmd file is run (importing the registry settings in your runonceex.cmd file to configure RunOnceEx), and then the next time the machine is rebooted and logged on, these registry settings are read in and installation begins. This is how it is supposed to be working. Perhaps try running your RunOnceEx.cmd file from [setupParams], so that it is imported BEFORE the first reboot, not AFTER.

You may have better luck posting this in the Office forum.

http://www.commandline.co.uk/cmdow/

Take a look at this newsgroup post and see if anything sounds familiar: http://groups.google.com/group/microsoft.p...2040319164e493e

Well, DEP (hardware) did a very good job of keeping the latest WMF exploits from running on both 32bit and 64bit Windows machines. I'm not sure I recommend full system DEP for 32bit systems simply because of the need to about double usage in both your kernel paged and nonpaged pool resources to monitor all of the areas DEP monitors, but on a 64bit system there's really no need not to (unless you have a specific application that has issues).

Which OS are you using, and what is the actual STOP code (and resultant stack data) when the machine crashes?

Do you have any Windows Updates installed? If you do, any of those updates that update shell components will update shlwapi.dll (and shdocvw.dll, which you also shouldn't remove).

I could've done that, but I don't have a box with NOD32 running on it at the moment. I actually thought of that this morning on my way into work, but it's been busy. And yes, I've got contractual obligations that... prevent me from posting internal Microsoft documents. It's OK though, I don't take it personally, and I always believe everyone has a right to their opinions, whether I agree with them or not (and vice-versa). Thanks for the vote of confidence, though, I do appreciate it . I love Fridays.