cluberti

On XP 32bit, userland processes are given 2GB of virtual address space, and the kernel is given 2GB of virtual address space. You can change this to 3GB/1GB by using the /3GB switch in the boot.ini file, but it does borrow virtual address space that would otherwise be used by kernel processes to give the extra 1GB virtual address space to processes, so it should only be used if you have processes that are actually attempting to allocate and use more than 2GB of virtual address space (Exchange can sometimes need this, as can SQL, for instance). On XP 64bit, a lot changes. XP 64 bit can address 16TB of virtual address space, rather than 4GB, thus making 8TB of space available for userland processes and 8TB of space available for kernel processes. The system cache available goes up from 1GB (32bit) to 1TB, and the kernel memory pools increase as well, for both paged (from 470MB to 128GB) and nonpaged (from 256MB to 128GB) pools. Currently, Windows 64bit versions have a limit placed on them in that the cannot access more than 1TB of *physical memory* (they can still allocate up to 16TB of *virtual address space*) in the machine, but it's a fabricated limit within the Windows code itself, not the architecture (the 64bit architecture can address 16TB of physical memory, but Windows 64bit can only access 1TB).

Good luck .

No, case doesn't matter for variables in Windows.

Has all of the information been populated in the directory? Is your Recipient Update service running properly? Try looking for more answers at www.msexchange.org - this is a fairly common issue if your RUS service isn't working properly, or you are having AD replication issues.

I found, at least for me, that taking mock tests helped me more than anything else after I had learned the material. I felt better prepared when I took my tests, and got better scores this time around than I had when I took the Windows 2000 MCSE tests.

Yes - software firewalls need a "hook" into the TCP/IP stack, in order to scan packets that are headed in or out of the box. Since all Windows XP SP2 and Windows 2003 SP1 machines already come with a hook for the Windows firewall, adding another seems like something you'd want to do only if the XP/2003 firewall didn't meet your needs. It's almost always OK to do, but I have seen firewall applications completely hose Windows machines.

If you got the CD's with your computer (OEM), you should contact the vendor with this issue. It's likely that your keys will not work with SP2 (there was a PID range, xxx-640-xxxxxxx, that were "blacklisted" when SP2 came out, and your product key may be generating a PID in that range).

Perhaps set the service from Manual to Automatic, and see what happens? It's a timeout issue between the service and the COM manager - as to why, I'm not sure. As for the SFC CD issue, if your CD isn't the same service pack level as the machine you're trying to repair, you can get these errors. If so, you'll need to slipstream your installation source with the correct service pack before it'll work.

Perhaps if you post the callstack information from the bluescreen, I can gather more data about the root cause of your errors from the debugger. However, I can tell you that the driver you mention in your previous post is from a Leadtek Winfast TV card (or other variant).

If you put the same registry entries that are inserted into HKCU for the app into HKU\.DEFAULT\ (in the same relative locations), these will get added to new users on the system automatically during profile creation. You can also do this by loading the hive from ntuser.dat in the C:\documents and settings\default user\ folder and inserting them into that hive.

It could be the firewall (best guess), but it could also be the video card. I'd also check and see when the last antivirus engine update to your A/V software was done, as I've seen this sort of thing happen before after Symantec A/V updates...

Well, it's definitely a driver causing this issue, but as to which I am uncertain. Did the bluescreen list any driver names? Configure your machine to NOT reboot automatically on a bluescreen crash and you can get more info (like the driver name of the module that was loaded into memory when the crash started). What I can gather from the bluescreen data is that some driver on the system has caused an IRQL exception, it's in IRQ Level (IRQL) 255 when it crashes, and it's a memory write operation. That's not all though, and here's the kicker - the only time an IRQL is at anything higher than 31 is when the system is crashing. What does that mean? It means that you have a driver on your system that caused the system to start a bugcheck (the technical term describing what the system does to start creating a blue screen of death, and setting the system to do a dump of memory to the pagefile for analysis, when an exception that the OS can not or will not handle occurs), and THEN the driver caused an IRQL error - so you've got a driver doing something DURING A SYSTEM CRASH ALREADY IN PROGRESS - a bluescreen on top of a bluescreen, in layman's terms. So you've got a seriously buggy driver on your system, and one that can be active DURING a bugcheck operation. Since only kernel-mode drivers can do this, it could be your antivirus software, your disk controller drivers, or your video or audio drivers. Hopefully the bluescreen said which .sys file or .dll file caused the initial bugcheck. Have you added or changed any drivers, or installed any software updates (Microsoft or otherwise) recently?

The second beta of IE7 does not seem to be affected. Another machine running beta 1 did appear to be vulnerable. Just an FYI.

If you use the following in WINNT.SIF, it should start with themes disabled, and the system in the "Adjusted for best performance" state: [shell] DefaultStartPanelOff = YES DefaultThemesOff = YES

I find nothing on the major search engines for either "Windows Genuine Advantage Notification" or "KB905474". So, this is odd.

Please post the actual blue screen data - including the stop code AND call stack data. Just knowing it BSOD'ed and recovered from an error isn't going to help us much in helping you, unfortunately. I think this should be a sticky - if you've got a BSOD, post the stop and callstack data!!!!!!!!!!!!!!

What's wrong with the Windows firewall? It's scriptable, doesn't require a special hook .dll into the TCP/IP stack, is configurable and manageable via Group Policy, and blocks inbound traffic just as well as any other software-based firewall out there. I know it lacks outbound firewall blocking, but I don't think that is a horrible thing if you know what is going on internally on your system. We all run antivirus and antispyware, right? Besides, just because you can block the traffic outbound of a malicious application doesn't remove the application from your system. The next version of Windows will include a two-way firewall, but this version of the Windows firewall is a good inbound firewall, and meets the original posters requirement of "light" (no additional hook .dll into the TCP/IP stack) and efficient (already integrated into the Windows GUI, and easily configurable via the control panel applet).

Those looking for dual core processors should be considering what they do with their PCs - if you play games and do some word processing and email/net access, a dual processor box is an expense that is (at least for the most part) not justified. However, for those of us who run multiple VM's, compile, and use threaded applications, the more the merrier. Anyone who is a "power user" (not gamer, but power user) will tell you that a multiprocessor machine performs better under load than a single processor machine, at almost ANY task. However, since both Intel and AMD have pretty much put the future in dual-core processors, you will see more threaded, multiprocessor aware applications within the next year or two. The MHz race has become the "more chips on one die" race, and it will be good for consumers in the long run .

I'd suggest the built-in Windows firewall for a firewall, and something like Trend, AVG, or Symantec for antivirus. Note to use Symantec Antivirus itself, not one of their shoddy security suite products!

The one thing to make a computer faster is to add physical memory (RAM), and conversely, a slow machine (assuming it's free from viruses and spyware) is almost always slow due to a lack of RAM. The 350MHz processor doesn't help, but the RAM is where the real bottleneck is. A PII 350MHz machine with 512MB of RAM can run Windows 2000 quite fast - it boots slow, and applications load a little slower than on a new machine, but the actual usability of the machine is quite good. Even 256MB of RAM would help a bit with this box.

Does "query user" give you what you need?

I'm not that dumb . But they reference KB articles (hence the KBxxxxxx in the name), but the KB articles don't exist...

Have you paged down to the bottom of the EULA before hitting F8?

I second RogueSpear's comments - I've found the same to be true on almost all RealTek NICs I've come across. Use the RealTek drivers for RIS, but the Windows driver everywhere else . Apparently, RealTek hasn't figured out how to write a decent driver. Perhaps they should consider using the Windows Driver DDK (in which even a trained seal could likely write a driver that works, but I digress)...

In your setup line for Windows Media Player, use the switch "/DisallowSystemRestore". This will remove the prompt.