cluberti

That is true, devil, but apps that are 32bit do benefit from running on x64 Windows due to the increased memory address space. Given the choice between 2GB and 4GB address space on a 32bit database, email, transaction (etc) server, would you not choose the 4GB address space over the 2GB? Yes, I agree using a 64bit app on a 64bit platform is preferable, but when that isn't possible, most 32bit apps run just fine on 64bit Windows, with the added benefit of not having to share their 4GB address space allocation.

I have a 2000 SP4+URP1 box - again, I can post the reg here but it may or may not work for you (you REALLY aren't supposed to delete those keys, they can be machine-specific). If the attached .reg doesn't work, you will have to use your CD to do a repair installation. keys.zip

Have you added any applications or made any program updates recently? Try running autoruns (www.sysinternals.com) and disabling all non-Microsoft items, reboot, and see if the problem persists.

Scandisk from Win9x was replaced by chkdsk in NT OSes. Run chkdsk /? from a command line to get options on how to use it. 23:23:48.74 Sun 02/19/2006 C:\>chkdsk /? Checks a disk and displays a status report. CHKDSK [volume[[path]filename]]] [/F] [/V] [/R] [/X] [/I] [/C] [/L[:size]] volume Specifies the drive letter (followed by a colon), mount point, or volume name. filename FAT/FAT32 only: Specifies the files to check for fragmentation. /F Fixes errors on the disk. /V On FAT/FAT32: Displays the full path and name of every file on the disk. On NTFS: Displays cleanup messages if any. /R Locates bad sectors and recovers readable information (implies /F). /L:size NTFS only: Changes the log file size to the specified number of kilobytes. If size is not specified, displays current size. /X Forces the volume to dismount first if necessary. All opened handles to the volume would then be invalid (implies /F). /I NTFS only: Performs a less vigorous check of index entries. /C NTFS only: Skips checking of cycles within the folder structure. The /I or /C switch reduces the amount of time required to run Chkdsk by skipping certain checks of the volume.

Actually, that's not entirely true. 32bit processes running on x64 now have access to 4GB virtual address space when running, rather than 2GB (or 3GB with the /3GB boot.ini option) in 32bit Windows. This can be a huge boon to 32bit application performance, like SQL 2000 databases or mail servers (not Exchange, as it doesn't run on x64 platforms), for instance. While they don't run in 64bit mode, they still get memory benefits.

Is the system freezing for more than a few seconds, or are we talking about a freeze of a second or two? Also, are you seeing any moments where CPU is pegged (80% or higher) for more than a second or two? I'll suggest the usual - let's get some perfmon data during the times it's happening and review for possible clues.

Mr. Snrub is correct here - the behavior is by design in an AD, and the only way around it is an http(s) proxy or autoconfig PAC or JS file in IE.

DirectX 9 is removed when installing SP1 - this is a "by design" thing. I second the recommendation for using DirectX Happy Uninstall, as it's the only sure-fire way I've found to reinstall DirectX 9.0c. Don't be surprised if it breaks again when the next SP comes out, but until then it'll get DirectX 9.0c back on the box.

And CPU problems generally don't produce bugchecks like a memory error would - usually you get complete shutdowns or lockups if the CPU has caused the issue (not always, but commonly). I'd say a good memory test is in order here - the only thing in common about all of the errors is that they seem to occur in processes that would run in kernel nonpaged pool, which would have it's virtual address space mapped to physical RAM at all times.

Plcae them next to the i386 directory in your image folder, and everything else is the same. Deleting files or creating a riprep image manually won't work (as you've already found out), but you can probably achieve the same level of automation by just using the flat file and runonceex scripting.

The results you are seeing are because you deleted the OLE key and it's contents - you either need to restore the OLE and LSA keys from a backup (your Windows 2000 machine or another at the same SP level), or do a repair install to get them back. Just creating the keys will do nothing.

Just an FYI on what serenum.sys is for: http://www.microsoft.com/whdc/system/CEC/serddvr.mspx

http://support.microsoft.com/?id=842933

You've got the descriptions backwards, but otherwise correct. However, I would strongly suggest against using the DisablePagingExecutive value unless you've got at least 2GB of RAM - becuase you're making sure that kernel nonpaged pool AND kernel pagedpool resource pools run in physical RAM, rather than just kernel nonpaged pool (pagedpool can be swapped out to the pagefile otherwise if the system becomes RAM-hungry). Why, you may ask? Well, if you've got 1GB of RAM in your machine, and you have both nonpaged and paged pools running in RAM, you have the good possibility of dedicating roughly 600MB of physical RAM just for kernel memory, instead of just 256MB - it'll be used as necessary by the kernel, and applications may start running in the pagefile rather than RAM on a memory-hungry box. If you have 2GB of RAM in your machine (or more), even with relatively full nonpaged and paged pools running in RAM, you'll be dedicating approximately 750 - 800MB of RAM to kernel memory, thus still allowing approximately 1.2GB of RAM for running processes. On systems with 512MB or 768MB of RAM with this "tweak" enabled (sarcasm intended), you'll see that running processes (and these running processes include system services, background apps, etc. - not just user-initiated programs) will have very little physical RAM to grow into before things start getting paged out like mad. The NT kernel's memory manager does a pretty darn good job of making sure that as much virtual address space as possible is mapped to physical RAM before paging out already, so this tweak really doesn't net much overall system performance - you're still better off adding more RAM, rather than modifying how that RAM is used. Obviously all of this goes out the window on x64 platforms...

What exact updates did you install?

Yes, but think of it this way: Windows 2000 was 5.0.2195, whereas NT4 was 4.0.1381, but they were still based on the same kernel - the same kernel that Vista is based off of. I would hope in 10 years (and two major revision builds from 4.0.1381 to 6.0.<whatever the final build number here will be>) would have heavy modifications .

Yes, this is Update Rollup 1 v2 which was released in September of 2005. http://www.microsoft.com/windows2000/serve...ins/rollup.mspx

Now maybe perhaps you'll admit that we all are really THAT good .

I wouldn't be able to answer the question about the system restore doing anything good or bad, because I have no way of knowing when the problem was initially occurring. As to the dump, thank you for uploading it, but I need a more complete dump, not a minidump. The dump file I'm looking for would be named memory.dmp, and be in the Windows directory itself, not the minidump folder. Minidumps don't contain much data, which is why I need to look at a real dump with real stack and thread data. Also, as to the glausb.sys file, I believe this belongs to your USB DSL modem, so you'd have to contact that vendor to see if they have an update (which is likely your ISP).

It's still an NT kernel, based on the same kernel 2000, XP, and 2003 have been based on (with all the requisite upgrades, tweaks, and changes since NT of course, and a few new ones). Vista is not a new product kernel-wise, but the GDI interface, file system goodies, and a few other apps are new.

This error appears to be happening in your USB driver, glausb.sys: I tried to walk it back further to see what IRP was still out there that was causing this, but because it's a minidump and not a kernel memory dump (memory.dmp), I can't see what's going on. I can at least see the thread, but there's no real info there: If you can provide me with the actual memory.dmp file in the Windows directory, I may be able to tell you where the actual IRP that caused the bugcheck is, and who owns it.

That's OK - I just mentioned those in case you were pushing those out via a Group or System policy.

Ah, but it's likely the drivers are the same - no sense ruling out a software issue if it's easy to determine (whether it is bugchecking or not).

http://support.microsoft.com/?kbid=265879&sd=RMVP fizban2 is right though - the error occurred because of your sound driver.