cluberti

OK. Another (recent, mind you) set of reasons to avoid nvidia hardware: G84 and G86 65nm chip problems (note that first link will end up with "nvidia-opens-whoop-a**-itself" in your browser's url. Change the *'s to "s"'s to see the URL. Silly filter) G92 and G94 55nm chip problems Dell has put up a blog post on the issue and HP has a "warranty enhancement" program for laptops affected by these types of problems (failure to boot, random beeps, video issues, wireless adapter failures, etc). That's quite an extensive hardware list, and quite the spectrum of nVidia chipset issues (and it looks like there are many more HP models affected than Dell models, but those are also some of the most popular models from both vendors, so...). Again, nVidia's fix basically does nothing more than to try and postpone the problems until warranty periods expire, so users cannot replace what nVidia (and HP, and Dell, and... you get the picture) know are defective parts. Not only shoddy engineering, but shady business practices. I can't say AMD/ATI are any better or worse, just pointing out the facts about nVidia's problems that relate to this thread.

One thing to test - install Windows from a CD (not an image), and don't install ANY drivers. If the problem happens on that new install...........

Also, check out the resource kit utility delprof.exe.

It would seem so, yes.

Unfortunately, you've given us only a minidump - so your dump is missing lots of info (like, potentially the memory information regarding the driver crashing the box). However, since this is a csrss dump and the parameter that's being passed is invalid, I'd suspect a memory dump without any further checking would just lead to a bigger file without any more data that would be useful. Also, most of the time I see this, it's one of three things - a processor problem relating to the BIOS (more with Intel microcode than AMD, but AMD processors do have their BIOS issues), a failing hard disk, or a potential antivirus interference issue (and seeing how old your symevent and symtdi files are, I wouldn't be shocked). So, assuming you run a chkdsk /r /f on your drive and it comes back clean, I'll tackle the other two: //1. You're running an AMD Athlon 64 3000+ processor, and I don't see anything odd // regarding the CPU itself, or the SMBIOS info - I'd say it's likely not a bad processor, // however you are running a REALLY old BIOS that you should consider touching: kd> !sysinfo cpuinfo [CPU Information] ~MHz = REG_DWORD 2000 Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0 Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0 Identifier = REG_SZ x86 Family 15 Model 28 Stepping 0 ProcessorNameString = REG_SZ Mobile AMD Athlon(tm) 64 Processor 3000+ Update Status = REG_DWORD 1 VendorIdentifier = REG_SZ AuthenticAMD kd> !sysinfo smbios [SMBIOS Data Tables v2.3] [DMI Version - 35] [2.0 Calling Convention - No] [Table Size - 732 bytes] [BIOS Information (Type 0) - Length 20 - Handle 0000h] Vendor American Megatrends Inc. BIOS Version A1011SMS V0.90 11/22/04 BIOS Starting Address Segment f000 BIOS Release Date 11/22/2004 BIOS ROM Size 80000 //2. Your symevent and symtdi files are both quite old, and known to be somewhat buggy: kd> lmvm symevent start end module name f3ae0000 f3afcdc0 SYMEVENT (deferred) Image path: SYMEVENT.SYS Image name: SYMEVENT.SYS Timestamp: Sat Sep 16 01:48:19 2006 (450B9023) CheckSum: 000209CF ImageSize: 0001CDC0 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 kd> lmvm symtdi start end module name f3b1e000 f3b5dda0 SYMTDI (deferred) Image path: SYMTDI.SYS Image name: SYMTDI.SYS Timestamp: Sat Jan 22 00:55:40 2005 (41F1EADC) CheckSum: 000500F3 ImageSize: 0003FDA0 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 One last thing to note, which I found odd - both processr.sys and tosrfcom.sys were in the unloaded modules list when the machine crashed, meaning it's also possible that the tosrfcom.sys file is the culprit. It's either the Toshiba Bluetooth stack driver, or a virus, so I hope you have the Toshiba software installed. Noting that this is not a Toshiba, I'm actually leaning on removing the Bluetooth software and driver entirely as well, as it's very suspicious to be unloaded along with processr.sys.

LOL

Are you sure you've injected the correct network driver for these devices? Also, you might want to consider increasing the TFTP block size, then recreate your boot.wim and ISO: http://technet.microsoft.com/en-us/library/cc731245.aspx

Better test - does it happen in safe mode...

OK - I was gonna post mine here, but apparently that would be bad. I would be hated...

I believe nuhi has stated previously that this is for personal use only, but you can PM him to see if that has changed.

That post was unwarranted (at best, a PM would suffice). Show some respect for someone who does this on his free time, or use something else. Rule 7b, read it. You have been warned.

Cacls.exe is a default XP binary.

Instead, and more useful, why not configure the system for a complete memory dump, so the next time it occurs you can upload the (compressed) .dmp file somewhere? Just looking at the data on the blue screen doesn't tell you anything about contents of memory, register states, stack info, or any other such useful info about the dump.

Hard disks can fail for a number of reasons, really. I would think the most common would be a head crash (read/write heads touching/skimming the platter surface, causing damage), but I've seen the air filters in a drive fail (the inside was dusty as hell) which caused bad sectors and death, and I've seen magnets fail which renders the motor useless (that wonderful clicking sound you hear during spinup signifying that the head can't be positioned due to magnet or motor failure). They can of course fail if they're running and they ... bang into something too, of course, but that's not as common as head failure.

I've noticed that using vlite 1.2 to remove languages causes file signature issues (thus, no boot). 1.1.6 did not have these issues. However, using the WAIK is pretty easy, and it doesn't break the image like vlite seems to (and it's not 100%, but it's more than 50% of images that end up this way).

Actually, you can download/make a DOS boot disk if you own the overlying OS (is that a word? ), which appears to be Win98. It's how bootdisk.com gets around these sorts of things, as there's no real EULA on boot disks.

You could create a vbscript that checked the Win32_Processor or Win32_OperatingSystem class(es) to determine if x86 or x64 is installed.

I've heard of it, I've used it, and I can find it documented on Microsoft's site.

Did you miss this? That's Windows 2000 for ia64 (Itanium). It *is* a Microsoft product.

Why do people copy and paste posts off of the internet? Closing. Warning handed out.

If you purchased it, you should have the CD key and the COA sticker. Contact Microsoft, they'll likely ask you to provide them proof of purchase via the key and COA sticker, and you should be able to get a new CD.

Hmm. Also look at any brandlog.bak files, as these are renamed every time processing takes place (and it can take place multiple times per login). However, I would strongly suggest creating a new group policy with only the IEM settings from an XP SP3 / IE7 machine, and remove the old GPO from the domain. If you create an IEM from a 2003 machine, bad things can happen on the client. In the new IEM policy you're modifying from the XPSP3/IE7 machine, JUST set the proxy, and see if it applies - then, go ahead and change the titlebar and logo, etc once you're sure proxy is working.

XP uses sysprep.inf, Vista uses unattend (or autounattend).xml.

Keep it clean. Warnings all around - if you don't start following rule 7b, I'll start suspending accounts. That goes for all of you, not one in specific. Keep it clean, and I'll let the banter go back and forth. If the lack of respect continues as-is, I'll put up the virtual roadblock from using the site for 3 days. I will generally let banter go back and forth, even heated, but if the fine line of rule 7b is crossed I *will* suspend accounts or ban and there will be no discussion.

The other problem with "speeding up" the Windows 2000 boot process is that it runs everything during boot serially, whereas Vista (and to a much lesser extent XP) will load only the most critical subsystems and drivers serially, and then load anything and everything that can load in an asynchronous fashion as such, and postpone services and drivers that don't actually need to be started during boot (like Automatic Updates, BITS, the kernel transaction manager, and the Security Center, for instance). You can make the *initial* bootstrap quicker via ntldr and ntdetect, but the OS load will still be entirely synchronous and there isn't anything you can do about that short of removing things from loading entirely.