cluberti

Have you tried running sfc /scannow, or reinstalling the latest service pack?

You should be getting an event in the eventviewer on a machine exhibiting these symptoms - any idea what the source and event ID number are for these? Usually, this is a network issue caused by a low memory condition - the storage space in question isn't a storage space issue that you'd think of as in disk storage, but as in space in memory to store another request. You can try a few things to get around this, but it's almost always a low memory condition on the workstation that is causing these errors. This can be caused by the server service running out of process memory, by a process on your system consuming memory handles and not releasing them properly (*cough*antivirus*cough), or even too many values in a particular registry key on the system (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes). You can try a few things on your workstations to see which (if any) of the following makes any difference: 1. You can modify the IRPStackSize parameter in the registry to increase the memory size made available to new applications. Key: HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters Value: IRPStackSize Type: REG_DWORD Data: 15 (can set as high as 50) The default in NT and 2000 is 11, and in XP and 2003 the default is 15. The allowed values are 11 - 50 for this entry. A higher number will result in more memory size available for new applications, but can cause issues on systems running large numbers of applications. 2. You can try increasing the "beef" of the Memory Manager in Windows by making the following changes (these need to be made as a set - you can't just set one or two, you have to use all or nothing or the changes won't make much difference): Key: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management ---------- Value: LargeSystemCache Type: REG_DWORD Radix: Hex Data: 0 Determines whether the system maintains a standard size or a large size file system cache, and influences how often the system writes changed pages to disk. Possible values: 0 - Establishes a standard size file-system cache of approximately 8MB. The system allows changed pages to remain in physical memory until the number of available pages drops to approximately 1,000. 1 - Establishes a large system cache working set that can expand to physical memory, minus 4 MB, if needed. The system allows changed pages to remain in physical memory until the number of available pages drops to approximately 250. ---------- ---------- Value: PoolUsageMaximum Type: REG_DWORD Radix: Hex Data: 3C Determines when the Memory Manager starts trimming the PagedPool area of kernel memory, to free up space for additional resources that may need space in the kernel's PagedPool memory area. The default for this trimming process is 80 percent. Setting the value at 3C (60) informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent, or even lower. ---------- ---------- Value: PagedPoolSize Type: REG_DWORD Radix: Hex Data: 0 Determines the size of the kernel's PagedPool memory area that is created during the boot process. Setting PagedPoolSize to 0 allows the Memory Manager to determine the appropriate PagedPool memory size during the boot process. ---------- ---------- Value: SystemPages Type: REG_DWORD Radix: Hex Data: FFFFFFFF Defines the number of system page table entries that are reserved for mapping I/O buffers and other information into the system address space. Each system page table entry maps one page. Possible values: 0x0 - The system calculates an optimal number of page table entries based on the platform type and the amount of memory available to the system. The system adjusts this value if the amount of memory changes. 0x1-0xFFFFFFFE - Specifies the number of reserved page table entries. This value takes precedence over the system's calculated value, and it prevents the system from adjusting the value. 0xFFFFFFFF - Maximize system pages. The system creates the largest number of page table entries possible within physical memory. The system monitors and adjusts this value dynamically when the configuration changes. Approximate values FFFFFFFF = tells OS to set the maximum number of PTEs allowed 24FFF = 150,000 PTEs BFFF = 50,000 PTEs 7FFF = 32,000 PTEs ---------- Otherwise, running perfmon against the machine in question until the machine starts exhibiting symptoms is the only way to see what, if anything, is using large amounts of memory, or if you have an application that is "leaking".

It isn't. Probably not until at least the end of Q2 2006, and maybe even later than that. The push to finish Vista takes precedence, and since there's not really enough of a backlog of hotfixes that need to be rolled up yet, there's no real pressing "need' for a Service Pack (at least from a technical standpoint) as they're mostly just an amalgomation of all public (and some private) hotfixes since the previous service pack.

Yeah, regmon's pretty verbose. However, you're looking for any entries that are "Not found" or "Access denied". Note that on the "Not found" entries, it may find the key or value it's looking for later on, so be careful - it can take the registry parser a while to find what it's looking for, and it may look in multiple locations for a key or value. Keep track of the "Not found"s that are actually not found, and note any access denied's immediately. Sorry I can't help you too much further, because regmon and filemon are a bit more low level tools than most GUI users are used to dealing with. It takes a pretty good knowledge of how the system works when it's actually working to be able to look at a regmon or filemon log and see what's "wrong" - it helps to know what it looks like when it's working . Sometimes, though, regmon or filemon are the only sure-fire way to find out just what's going on within the system's "guts". It's good to find out when things aren't working, and it's also good for those times when you think "I wonder what happens when I click this, or make this change here..."

Usually, this is because of missing class ID's in the registry (CLSID) - you'd need to run regmon on the system when trying to do the failing steps though, to see which CLSID comes back as not found.

Well - do you have a Windows 2000 CD that isn't nLited that you could use to compare the format times? Perhaps it's an nLite issue, maybe it's an issue with how Windows 2000 setup is accessing your drive - without knowing how an unmodified Windows 2000 CD performs, I think we'd be just guessing at what is causing the issue.

Are you saying that group policy objects that you have deleted are being applied to this new computer, after it has joined your domain?

Ok, go into the Control Panel, open up the Internet Options applet, then go to Tools > Options > Advanced, and uncheck the "Enable third-party browser extensions" setting. If you do that (and close all IE windows before trying again), do the problems still exist?

It's the same kernel as XP Professional. The MCE components are "bolted on" to the XP source, similar to the way the TabletPC version of XP works.

[setupParams] launches it's script at T-9 during setup, and is good for launching applications and registry entries because at T-9, the OS files have been completely installed - the registry is still in default user mode and the registry needs to be built, but otherwise the system is installed. This can sometimes be the best time to install Windows non-critical updates (like the .net framework and Windows Media player, etc.). [GuiRunOnce] launches the contents of it's script after a user first logs on, after Windows setup has completed and restarted the machine one last time. This method is sometimes necessary for applications that will not (or should not be) installed during the Windows setup process itself. I'm partial to using a script that is called in [setupParams] to enter default user registry settings, and entering the registry values for all of my applications to be installed into the RunOnce section of the registry.

Note that Windows XP and Windows 2003 64bit editions (except 2003 datacenter) can't address more than 1TB of physical RAM... It's not a hardware limitation, it's an artificial one in the Windows codebase itself. Just an FYI.

What is the actual bluescreen stop error, and what is the callstack information? I've been using SAV10 here just fine on a few machines, but it's likely irrelevant to your situation ("works fine on my machine!" ). If you can post the stop hex code, the callstack data, and any .sys or .dll files that you see in the dump data, that would be great. It would be good if I could look at the minidump .dmp file as well, to debug it...

The driver is obviously the nvidia driver, but what is the actual stop error in hex, and what is the callstack data?

Take the guesswork out of driver support - http://www.hcl.ms.

This can happen if a single-threaded application starts a thread on the second CPU. If the thread on the first CPU has to wait on the thread running on the second CPU, you get ntdll in a criticalsection wait state - the first thread is waiting for some data returned from the second thread, but since the application is not multi-processor aware, the second thread isn't able to access the first thread on the other processor. Setting the processor affinity is the only way to get around this issue (or cleanup the application's internal code ). I see it happen with some regularity, and the debugger always shows a thread running in a loop, or a thread spawned on a second processor that causes the first thread to hang (and start eating up CPU time, too). I'm not saying this is what has happened, but it's possible.

You'll probably have to check out the WTS API's on MSDN, then, as that's the only other way I know of getting info from a TS machine. http://www.microsoft.com/msj/1099/terminal/terminal.aspx

If you have uphclean on the box, it's supposed to be fixing this issue - it should also tell you what it had to do to unload the profile. If it isn't working, perhaps it isn't installed correctly?

Well, I don't actually remember how long I studied, but I was an admin at the time working on the stuff on a daily basis. It does hurt if you can't work on what you've learned at least regularly, I'd wager. They are trying to do away with the "paper MCSE", so the tests have gotten tougher since the NT4 (and even W2K) days. I'd think that being hands-on along with the reading and test-taking is almost a necessity if you're going to pass the tests with good scores.

Does this happen to new accounts as well, or just pre-existing accounts?

You can't, short of having a key generator. Even then, you can't be entirely sure of the results (although most generators are pretty good at being correct in determining). The keys for Windows aren't decodable (well, ok, key generators can do some of the work), so you'll have real trouble determining a retail vs VLK product key. I guess you could always run it through a key generator that does some checking on the PID that a key creates, but otherwise, I think you may be out of luck. You aren't supposed to be able to verify this info from the key itself, but you can get some info from the PID that Windows creates from the key (which is what the keygen is likely doing).

Windows XP product keys themselves are not able to be decoded in any way, so you cannot look at a product key and determine it's matching product. You can use the setupp.ini file from the original disc to determine if the disc is a Home or Pro disc, but you can't take a key and determine whether it's a "Home" or "Professional" key. It is not possible without access to the database of keys, which none of us is likely to have .

Use a utility called "devcon": http://support.microsoft.com/default.aspx?...kb;en-us;311272

At least thusfar, Vista is slated to be the last true 32bit OS from Microsoft. Some of their server applications are already going to be released 64bit only (Exchange 12, for instance), but it probably won't be until late 2007 or into 2008 that 64bit home and business computers become more mainstream. Since it usually requires a hardware upgrade for most people to get new versions of Windows, we're proably waiting for that to happen en masse. Once people actually have 64bit computers PRELOADED with Windows 64bit, we'll start seeing regular, everyday commercial apps go 64bit as well. I doubt we'll see a huge swell for at least another 2 years, though, perhaps longer. Windows Vista 32bit will be around for at least a few years after it's release, likely 4 or 5 at least, remember, and the biggest consumer of Windows products are not consumers, but businesses. So it'll likely be after 2010 that almost every application is 64bit. I'd like to be proven wrong, but remember how many 16bit applications were around, even after Windows 98SE was released? Quite a few, and it took Windows 2000 to kill most of those off (5 years after 16 bit should've been dead). I'd like the 64bit revolution to happen quicker, but I highly doubt it will.

Just installed it myself on x64 - very nice .

On a working x64 machine, you should have both a ProgramFilesDir and a ProgramFilesDir (x86) variable. Just type the "set" command to see the directories for each variable.