cluberti

You can thank the Eolas patent ruling for this, too.

This appears to be a common occurrance for .NET users: http://www.microsoft.com/communities/newsg...dc7d18e&p=1 Unfortunately, it isn't the first framework update to cause this issue either - read Stebner's blog for a (not very nice, but effective) way to fix this.

Well, it doesn't necessarily mean the CPU is bad, but it's probable. With the cache disabled, the CPU has to do everything it would normally do in L1 and L2 cache (microsecond access time) in system RAM (milliseconds access time, which is 'years' in CPU terms). If you can boot and run (well, what would pass as running Windows on an 8086 ) with the L1 and L2 cache disabled, I'd say a new processor (or, better, a new CPU/mobo/RAM combo) is in order.

Has he perhaps attempted to run any applications from the network share directly (stored the app there and launched it from there)?

I'm not sure the OP is doing software development, and if he already has the software he needs installed, technically the IT staff was legally bound to lock the laptop down if it belonged to the department (I have relatives in the department who are complaining about this very problem too, but there's nothing they can do short of wait for a reversal of the directive, which probably will not happen).

So...? It's a true answer, and those users are the reason spare machines are even needed. I guess the real question is why did that user have access to delete critical system files...

You do realize you're opening your box up to security compromise by doing that, correct? Giving a very, very specific and limited account global admin access?

I'd strongly suggest installing a different print driver (especially if you can find one that comes with Windows that is similar) to see if the problem persists with the new driver (uninstall the old driver before doing this, if you are able). These are almost always print driver issues.

OK - I went ahead and played around to see if there was a good workaround, and found the following. Since safe mode loads up specific control sets in the registry, renaming these keys should "break" the loading of the relevant data to support safe mode. Note this doesn't actually disable the ability to press F8 and choose safe mode or safe mode w/ networking, but causes a bugcheck if someone tries to use it (so, I guess it's achieving the same ends): Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SafeBoot Under the safe boot key, you should see two keys called "Minimal" and "Network". If you rename these keys (say, to "Minimal-disabled" and "Network-disabled", Windows will now not be able to load these hives when entering safe mode or safe mode w/ networking, and will bugcheck. Note that an admin with registry access can revert this by renaming the keys in regular mode, and disabling safe mode could conceivably come back to bite you, but this should achieve what you want to do. Note that it does not remove the safe mode options (again, these are presented by the boot loader before the registry hives are even loaded), but will keep people from being able to use them until the reg changes are reverted.

The reason I asked is because it's the installation of Office that causes the Windows Update svchost.exe issue - the extra updates to Office cause the xml file used to track updates to grow from a few hundred kilobytes to a few megabytes, and the msi engine which is parsing the file gets bogged down with all the allocs and deallocs necessary to store and scan this file - essentially, the file becomes too large to handle and the msi engine a/v's constantly, causing it to consume the CPU as it tries and retries things over and over again until it succeeeds and moves on to the next stage. You might find that installing the Office updates manually helps, but if those two updates do not resolve the issue I would suggest contacting Microsoft for assistance (you should be able to get a free case for a hotfix issue). This is a known issue, and the fix isn't 100% effective, unfortunately.

"OK, here's a new laptop/PC. You'll have to reconfigure it, and next time, ask me to delete the files please. Thank you."

<meant for another thread - don't post while sleeping>

If the hotfixes are installed and you still have the problem, try uninstalling Office (bear with me here) and trying Windows Update again - does the problem persist, or does it go away?

Install 927891 and 932494 to try and alleviate the issue, as that is what those hotfixes are for. This can also be found by searching the forums.

If you ever log on to the server (either at the console, over RDP, or starting an application as a service under that user account), you get a profile. Accounts that have never logged on, should not have a profile.

You need to configure options 66 and 67 on the DHCP server serving any segment that will use this server - 66 points to the FQDN of the server, and 67 points to the boot file. That is all you should need to do. For reference, on my DHCP server servicing clients I wish to use a WDS server on my network, I have: 66 - server.domain.com 67 - \Boot\x86\pxeboot.com

One other question - if you create a printer that prints to a file, can you print the document successfully to that printer from the failing machine?

Now that you've got Windows installed, can you disable the L1 and L2 cache on the proc and reboot - does the error occur?

And a NAT router only protects against unsolicited incoming threats - it doesn't protect users from themselves (IE open a virus attachment, download/run a virus disguised as a program, etc). I guess you could say it protects against "active" threats, but not "passive". I've seen too many people install a NAT router and then remove firewall and A/V from their machines internally thinking they're magically protected due to the router. Also, firewalls on internal machines are still pretty important, as if a machine inside your network gets infected with a propogating virus, the other machines are not protected by the router . It's the "crunchy outside, chewy inside" network philosophy that I don't agree with - don't trust the other machines on your network behind your router/firewall too much, or bad things can happen.

This is normal - you need to open a command prompt by right-clicking on the icon and selecting "Run as administrator", or use runas to elevate, before you can run regsvr32 with UAC enabled.

They can be restored anywhere.

Both the intranet website and the mail server are accessed/connected to by an IP address (aaa.bbb.ccc.ddd), not a (DNS) name. I have only one certifcate for both. The certificate shows that IP address for both 'issued to' and 'issued by'. In the certificate information I cannot find a FQDN, but I am not that knowledgable about certificates and security in general, so maybe I am overseeing it. Does that answer your question? If not, let me know. And thanks for your time & effort! Regards, Frank I think that is part of your issue - Outlook 2007 generally requires a certificate that is valid to a host name, not an IP address. You might want to contact your ISP to see why they don't have a cert for something like <mail.yourisp.com>. I think you may need a new cert and use an FQDN for this to work properly going forward...

You're not dumb, but you really should read the help (specifically the "Back Up, Restore, Copy, and Import" section) when you're stuck before you post. But, to help you out this time, you need to click the "Group Policy Objects" folder in the left pane, and then right-click the GPO in the right pane to get those options.

One question - is the server certificate you are using for POP3S using the same FQDN as the FQDN you use to connect to the mail server?

I think I've already mentioned that this is built into the NT binaries used to load the machine. Modifying this menu means modifying the source and recompiling these binaries. Since that would be highly illegal, you are SOL. There is no workaround - if your users are using safe mode to use the machines, perhaps an administrative approach would be best suited to resolve this issue, rather than a technical approach.