cluberti

Regardless of the processor, yes, only one processor core.

Not being able to do much shouldn't be equal to not playing all games on a gamer's machine - I personally use mine for everyday tasks along with a hefty workload, and find it a perfect match for both. I do agree, however, that currently x64 machines are only really helpful to people who plan on using their boxes with certified drivers, 64bit software, and the kind of workload a 64bit machine was designed for before they'll see any real differences. Just wait until Exchange 12, however, and at least Server 2003 x64 will have LOTS of converts .

Does your Windows 2000 installation CD contain SP4 slipstreamed in? If not, you will have issues seeing all 200GB (even formatted NTFS).

If you are using a machine other than the Exchange Server to look at Exchange-related tabs, you need to at least install the Exchange Admin tools on that machine from the Exchange CD, and also install the same service pack on said machine as is installed on the Exchange Server itself.

http://www.microsoft.com/licensing/highlights/multicore.mspx "Q. How does this licensing policy affect products such as Microsoft Windows XP Professional? A. Microsoft Windows XP Professional and Microsoft Windows XP Home are not affected by this policy as they are licensed per installation and not per processor. Windows XP Professional can support up to two processors regardless of the number of cores on the processor. Microsoft Windows XP Home supports one processor."

Well, running perfmon in high CPU mode would definitely help.

The section should be called [sysprepMassStorage], and unless you're using SCSI devices, you may wish to omit those lines. They've been known to cause issues at times on older IDE/ATA systems.

Unlock the taskbar and drag it back to the other monitor.

In an NT-based OS, a reboot shuts down all winlogon processes, explorer, all svchost and other service processes, then the Service Control Manager (SCM). It unloads all process DLL's, then initiates a system shutdown of drivers and the kernel. You will find that doing a "soft reboot" on an NT OS is impossible. If you simply need to reload shell .dll's, killing and restarting explorer is usually enough, but a complete "soft" reboot is impossible.

Try running performance monitor (perfmon) on your system for a few hours, then review to see if you have any process or memory anomalies. Are you seeing high cpu spikes? Is your memory usage up from what it was before the issue started?

Mr Snrub, that's correct and a bit of a known issue with Process Explorer. Their message boards suggest doing just that - downloading the complete symbols for you OS. To BlueMe, you are having issues opening programs on your PC, although you appear to have quite a bit of free RAM. This means that likely you've started running low on one of the following system resources: Free System Page Table Entries (PTEs) Kernel PagedPool Memory Kernel NonPagedPool Memory Desktop Heap Memory To find out which of these is possibly at or near depletion, you are going to have to do some system monitoring - and to be honest, I would normally suggest doing what Mr Snrub suggests and actually debugging the running OS - however, debugging for a "noob" can be somewhat difficult, and that's why I suggested GUI programs such as Process Explorer and Performance Monitor (perfmon). If these are too difficult, you will likely not get to the root cause of the issue. I hate to be harsh, but you want to determine why the OS isn't doing something it normally would, so you're going to have to do some non-noob things to get that information, and short of using a debugger, you're going to need to use perfmon and Process Explorer. Wish I could help more, but what you want to determine can't really be determined other than debugging or monitoring with process explorer and perfmon.

It's also wise to note that there are differences in the 64bit implementation between Intel and AMD chips, with the AMD chips currently having the upper-hand currently in their implementation of x64 regarding performance.

32-way processing, 8-node clustering, 64GB RAM support, NUMA support... Pretty important stuff if you need it, some of which you can't get in 2003 EE. Datacenter isn't for everyday workloads, but for high-end work requiring lots of processing power and high availability. It's basically EE on steroids (and hardware tightly controlled by Microsoft and the major OEM's - you can be sure the OS is certified for the hardware and drivers when you buy a datacenter box or boxes).

http://www.microsoft.com/downloads/details...&displaylang=en

Have you tombstoned all of the records for the old machines in the WINS database, and cleared out the NBT cache on the workstations? Also, was this a domain migration, or did you simply create a new domain and migrate all the machines over?

In cases like these I always recommend process explorer (http://www.sysinternals.com) to determine what is using the CPU - you can break it down by process, thread, and even modules within threads if you so need to.

You can get the same information with a mix of Process Explorer (http://www.sysinternals.com), the _NT_SYMBOL_PATH environment variable set to the public Microsoft symbol server (http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx), and perfmon (start > run > perfmon).

The first error message means that you have a process that is holding open it's portion of the registry, and Windows cannot unload your user profile until this process releases it's grip on the registry. This is usually caused by Antivirus applications, and print drivers. You can install UPHClean from Microsoft to remedy this situation if it isn't being caused by A/V or drivers, as this service forcibly unloads the registry when a user logs off. This can cause a loss of data if the process that it forces closed has files open, however, so be aware of this - it's better to determine the cause of this if you can, because UPHClean does modify the way Windows works. The second issue can be resolved by making the following registry change: Key: HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters Value: IRPStackSize Type: REG_DWORD Radix: Decimal Data: 11 Close the registry editor and reboot for the changes to take effect. Note that if you are using the Norton/Symantec Internet Security suite, this should be set to 10, rather than 11 (the Internet Utilities suite has some issues when this is set to 11, the highest value, and Symantec recommends 10 instead for this value). After making these changes, see if explorer.exe is still crashing on you - if so, we can debug it to determine what module or thread running in the explorer.exe process is crashing it.

Yeah - and if we release antivirus software, watch a good portion of the world accuse Microsoft of monopolistic practices. It's a no-win situation, although issues like these are why I'm glad the world will ultimately move to 64bit computing in the next 10 years or so. Apparently Windows Defender will have a subscription antivirus package, so I guess ultimately we are going to get into the antivirus and antispyware markets "officially" when that comes out of beta. For those of us who are employed by MS... duck.

I'm not entirely certain - run filemon (http://www.sysinternals.com) while deleting the file to see who is placing the file back - it's not a regular file (although oledb32.dll is), so it is entirely possible that foul play should be expected. You could also try running autoruns (again, www.sysinternals.com) and disabling all non-Microsoft items and rebooting to see if you can't delete the file without it returning as well - obviously if that works, it's a non-Microsoft startup item or service causing the issue, and re-enabling things until the problem returns is a good way to figure that out if this is the case.

I personally have grown to prefer the x64 environment, but I run a plethora of VMs and compile a bit of code on this box, and the x64 address space has helped tremedously (I no longer need a server OS to run 8GB of RAM). I find it more responsive and more forgiving for the way I use a PC, but the decision to run an x64 OS is ultimately up to whether or not your drivers are certified to run in x64, and the applications you have will run. You will not be able to run 32bit antivirus or antispyware applications either (or any other application that uses a 32bit filter driver for that matter), so be aware of that as well.

We also have this problem with ATI Radeon drivers - I was going to ask if you had a Radeon card . Nice to know we aren't discriminatory - we have issues with both ATI and Nvidia cards .

Enable logon auditing and process auditing in gpedit.msc (computer configuration > windows settings > security settings > local policies > audit policy > Audit logon events / Audit process tracking (set both to success and failure) Then, the next time you log on, check your security log - it should show the logon, processes being started by SYSTEM, and then the logoff. Whatever process is loaded by SYSTEM before the logoff event is triggered is likely the suspect.

This can be done via sysprep and some other tricks, but it's not going to be easy. If you can't use a network install method such as RIS (or http://unattended.sourceforge.net/ or similar), let me know. I still have my scripts and basic image structure from when I had to do something similar. Note that scripting installs via RIS is much more supportable in the long run, but that also takes time to get right. You may not be able to do this, but if you can I'd strongly suggest it.

It can be done with sysprep and a few other tricks, but it isn't easy. If you're still interested, and can't use a network-install technology such as RIS (or http://unattended.sourceforge.net/ or similar), let me know.