cluberti

Just because a driver is malfunctioning doesn't mean that lspfix is going to find anything, as it only scans for errors in the winsock stack. You'd be better off considering Avira antivir, if you really want a recommendation. As to learning how to do it, you first are going to need to understand the programming language(s) involved in what you're debugging (in the case of Windows, you need C and C++, and you may need some .net language and runtime knowledge as well), as well as a decent understanding of how the system works (otherwise, it's really hard to spot when it's not working). Debugging in and of itself is just running commands, but knowing what to do and when takes skill and experience (more of the latter than former, as well). I am not trying to dissuade you at all, so don't think this is a post to do so - I just want you to understand that it's not as easy as it looks. If you are serious about learning, I would recommend learning to program (if you don't already) as a first step, preferably in C or C++. Also, you need to learn a bit more about the internals of Windows and how it works, so pick up Windows Internals 4th Edition by Mark Russinovich and David Solomon. Once you've gotten decent at writing your own apps (you'll pick up some debugging there, as you will find it sometimes necessary to do so to make your apps work), you're going to need to read a bit about some more advanced debugging techniques and tools as you go, so pick up Advanced Windows Debugging by Mario Hewardt and Daniel Pravat whilst you start debugging everything you can get your debugger into. And ultimately, practice, talking to others who do this well, and experience over time is what will ultimately give you what you need. Good luck, if you decide to travel down this road - anyone can write code, and anyone can be an admin, but to be able to do all 3 is something few can do, and something most people want to find. These are good skills to have if you plan to use them, but you'll find that it takes a few years (and then some) before you're good at all 3.

Minimum requirements for Win7 as from Microsoft are 16GB of HDD space for x64, assume similar (slightly less) for x86, but I'd doubt not too much less. As others have mentioned, anything less than 40GB is probably going to be incredibly tight.

Since you've seen the other post, I won't go into many details, but it looks like the AVG layered service provider (LSP) network filter driver was at fault here. There was obviously a network request work item on this machine that either did not complete, or a socket operation timed out - either way, the TCP TCB has timed out, and is being closed. As with most LSP filter drivers, any activity on the tcp stack in TCPIP.sys (network-related or otherwise) filter through it, and it looks like avg's filter driver came in and did something (can't tell what) as would be expected with AVG installed. Once it's done handling this request as it passes through, it has to send it off to afd.sys to be handled - except, it appears that the driver has munged the ecx register that is being registered by the KeAcquireInStackQueuedSpinLock, and thus the machine is going to bugcheck. See: 0: kd> .bugcheck Bugcheck code 1000000A Arguments 000000e8 00000002 00000001 806e6a16 0: kd> k ChildEBP RetAddr 805510b8 804fc4aa hal!KeAcquireInStackQueuedSpinLock+0x26 805510d8 b4b0bf95 nt!KeInsertQueueApc+0x20 80551108 804f16c0 afd!AfdRestartConnect+0x172 80551138 b4b1fcb1 nt!IopfCompleteRequest+0xa2 WARNING: Stack unwind information not available. Following frames may be wrong. 805511b4 804f16c0 avgtdix+0x1cb1 805511e4 b4b63942 nt!IopfCompleteRequest+0xa2 805511fc b4b69471 tcpip!TCPDataRequestComplete+0xa6 80551210 b4b6f1be tcpip!TCPRequestComplete+0x12 8055123c b4b69491 tcpip!CloseTCB+0x1ad 80551258 b4b6f80b tcpip!DerefTCB+0x60 805512d0 b4b5f3ec tcpip!TCBTimeout+0x7ec 805512e0 8050220f tcpip!TCBTimeoutdpc+0xf 805513fc 8050232b nt!KiTimerListExpire+0x14b 80551428 80545e7f nt!KiTimerExpiration+0xb1 80551440 8055be60 nt!KiRetireDpcList+0x61 80551450 80545d64 nt!KiIdleThread0 80551454 00000000 nt!KiIdleLoop+0x28 // The registers showing the register addresses - note ecx is within the first 64k, and as // you know from the post you linked, that memory is PAGE_NO_ACCESS: 0: kd> r eax=805510cc ebx=8980e870 ecx=000000e8 edx=805510cc esi=00000000 edi=8980e870 eip=806e6a16 esp=805510b8 ebp=805510d8 iopl=0 nv up ei pl nz ac po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212 hal!KeAcquireInStackQueuedSpinLock+0x26: 806e6a16 8711 xchg edx,dword ptr [ecx] ds:0023:000000e8=???????? // Here's the eip register unassembled, so you can see why ecx being invalid is bad: 0: kd> u eip hal!KeAcquireInStackQueuedSpinLock+0x26: 806e6a16 8711 xchg edx,dword ptr [ecx] <- // Trying to write to ecx from the memory address pointer in edx 806e6a18 83fa00 cmp edx,0 806e6a1b 7507 jne hal!KeAcquireInStackQueuedSpinLock+0x34 (806e6a24) 806e6a1d 83c902 or ecx,2 806e6a20 894804 mov dword ptr [eax+4],ecx 806e6a23 c3 ret 806e6a24 83c901 or ecx,1 806e6a27 894804 mov dword ptr [eax+4],ecx // The AVG module in question: 0: kd> lmvm avgtdix start end module name b4b1e000 b4b36900 avgtdix T (no symbols) Loaded symbol image file: avgtdix.sys Image path: avgtdix.sys Image name: avgtdix.sys Timestamp: Wed Dec 10 06:50:42 2008 (493FAD12) CheckSum: 0001B178 ImageSize: 00018900 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 I believe that is the latest version, so if you're stuck using AVG I'd suggest reporting this to their support folks to fix. However, if you are OK using another A/V vendor, consider removing AVG and using a more stable package.

No, and I have the same board and drivers with no issues. You might want to go into the mixer or the properties for your speakers in playback devices and make sure it isn't specifically set artificially low there (obviously do this with WMP12 running and playing audio, otherwise it won't show up in the mixer). I had those problems with my headphone jack, but for some reason the audio driver had set it to a default volume of "2" (out of 100). Dunno why, didn't do that on a reinstall of 7022 or 7048, so it might also be a build 7000 thing.

Anyone who spouts the "Windows 7 is teh DRM evil!" to claim why their system performs poorly, their sound or video doesn't work as well as it does on 2000 or XP, or that the protected video path or audio path code causes the machine to otherwise behave in an erratic manner is obviously being either deceitful in hopes to find some way to trash Win7 or really has no idea what they're actually discussing, nor doesn't bother reading up on how it works (and doesn't). Unless you're actually playing PROTECTED content that requires endpoint protection (whether it be for video, or audio, or both), Win7's DRM doesn't even get involved in the playback of media, period. If you are playing back or recording unprotected/non-DRM content, there is no reason for Windows' DRM to be the root cause, as it's just not possible. However, if you *are* having poor recording or playback performance, most times this tracks back to an app not designed with the new Vista-era audio or video subsystem in mind (these subsystems were changed *drastically* from XP to Vista and beyond, and thus an app not written with these in mind is likely to not perform to the levels they should), or as is far more often the case, back to poorly-written video or audio drivers (or again, both), not Windows. And Creative and Nvidia, I'm looking squarely at the both of you - your Vista-era drivers suck, and suck badly, to the point where people notice. There, I said it. I'll move on. Not liking DRM is one thing, and I have zero problem with people who oppose DRM just because it is a restriction on media usage, regardless of whether or not I side with you on whether or not certain DRM implementations are bad or not. However, being dishonest and disingenuous about it is another matter entirely, regardless of whether or not the intent was malicious or moronic (and again, in the linked case the OP quoted above, it does seem to be the latter with a dose of the former thrown in for good measure). The tinfoil hat-wearers among us have always despised and spouted off against DRM in Windows (and to be fair, other OSes, but we're discussing Windows right now), so that's to be expected, but the rhetoric as of late has gotten more virulent (and more wrong), and I have to think that either they truly don't believe that the people from within and without Microsoft are being honest about how it works, or they truly are being malicious and trying actively to discredit the Windows OS in an incorrect and deceitful manner. And, given how wrong the rhetoric is, I really don't know which is which, and I have lost a good amount of faith in humanity as of late, so I'm leaning towards the latter, even though the tinfoil-hat wearers might be doing the former and just being overly paranoid for little good reason. And may I ask why? It seems obvious that it's not the WGA or licensing changes brought about by Windows activation in XP that you speak of, so I'm going to likely rightly assume that it's the potential for protected-mode playback DRM code in Vista and Win7 that you speak of as somehow invading your privacy (it doesn't make sense, but I've got to assume that's what you mean, considering the tone and intent of your original post). Ultimately, if you don't want to deal with DRM on protected media (and again, that's the only time Windows' media DRM code gets invoked), then stay on XP and don't buy any protected video or audio, apps to play them on XP, nor any other DRM-protected media (and no, switching to OS X doesn't preclude you from the DRM built-in there to allow said content to play either). Also note that for the same reason, you shouldn't buy HDTVs, high-dev BR or HD-DVD players, nor any other commercially-available software or hardware to play said content either, as all of those will also have DRM on them so that the media will play, because it's *required* for content playback that the device or software have the DRM necessary to do so legally.You either have an OS, TV, and other playback hardware and software that is free of DRM media code, but is also free of the ability to play said content, or you buy an OS or hardware with the ability and live with the DRM. If you want those options to change, take it up with your congresscritter and any other politician that will listen, and good luck with that.

The other problem you should consider is the PSU, as it is *drastically* underpowered for anything "high-end" at 250W with the 3450 Radeon config. You won't be able to get anything "good" for gaming unless you can also replace the PSU with at least something at 350W or higher (and as others have mentioned, you also have to consider that you need a half-height card to put in there, or it won't fit - I also note that the hard drive bay is fairly close to the end of the PCI slot, so a full length card is likely not to fit either). Honestly, if you are not married to the Dell for the size, simply removing it from it's current housing and putting it into a standard ATX case will allow you to upgrade the PSU easily and put whatever card you want in there without the size constraints.

Correct - the beep pattern indicates either a faulty video card or potentially other faulty hardware, like RAM or disk. I would strongly suggest memory testing and running a hard disk test as well, as a HDD used for quite a long time might have some serious wear that only a prolonged period of inactivity would bear out (anyone else have a drive on 24x7 for 3 years, and then shut the machine down for a day and have it not work? Yeah, happened many times - I suspect either video or HDD). The disk might be fine, but swapping the video card and doing a thorough hardware test won't hurt. I know you say you do not want to due to frequent power outages, but considering the alternatives, I would strongly recommend a very deep and thorough test of all the hardware in the machine. 10 year old hardware is bound to have problems that being dormant for 6 months could have brought forward. Moving to hardware hangout, as this isn't an OS problem.

Agreed. The file is virus free, according to virustotal.com, but after running it in a VM it didn't seem to do anything useful other than popup hello world messages and "isn't china great?". I'm not even gonna virus scan the VM, just delete it. Program is specious at best, posted in the wrong forum, and from a user with no track record. It gives me enough of a bad feeling to shut this down. Thread closed, file deleted, user banned.

No, it was used to provide search in Vista to the most commonly-used area of the OS, the start menu. Again, one man's hectic is another man's wonderful.

The error code maps to a divide by zero error, or a database lookup error. Considering the source (RDP), I'd say it's potentially a network driver or LSP driver installed on the stack not handling something during boot that a reboot seems to clear. Hard to say, but my money would be on one of those two things (or even both!).

Download process monitor from sysinternals, run it, click Options > Enable boot logging in procmon, and reboot. Once you've rebooted and the system is finally up, open procmon again and you will be able to see what happened after the reboot, from kernel load to the time you opened procmon.

Well, one man's useless is another man's treasure (I personally very much enjoy integrated search and the superbar dock - the old start menu was clunky and inefficient. Yes, it reinforced motor memory on how to get somewhere in your start menu, but it wasn't efficient). And, I guess unfortunately for some, the code is no longer there, I am sure of that. And I would disagree about threads on forums confirming your view that the classic start menu is the best - the most vocal are almost always the minority, very rarely is it someone who likes something that goes out and pontificates on it's goodness, rather it's the minority malcontents that complain about what was. Noise does not denote majority, only noise. I'm not saying you're wrong, but I am suggesting that you are potentially in the minority. If you like classic, you're probably stuck with Vista or finding a way to replace the shell in Win7 (perhaps Stardock will have a way to do this when they are Win7 compliant).

There is a bug in sysprep on XP and 2003 wherein when you have an admin password set in the image, and you don't set a password in the sysprep.inf file, this happens. Unfortunately, it's easily reproducible.

I would suggest saving off a "working" ntuser.dat profile, then compare it to one that breaks over time to see what is different. You can load .dat hives in regedit to compare. This is usually a problem with the print driver barfing into the user profile's registry, but I've seen other things cause it.

This would be one of the scenarios where using nLite might be a good idea.

You could run a process monitor log to see what is happening.

This has me a little confused, if the RAM above 4GB is mapped as a RAMDISK, and the swapfile is located there, how would it perform any differently than a swapfile on a hard drive (other than being much faster since, well, RAM is fast)? What I mean is, I don't understand your comment about needing to ''move the code.'' I do understand that, using PAE, code above the 4GB barrier can't be directly executed, but that's not what would be going on in this case; the RAM above 4GB is just a RAMDISK used to hold a swapfile. Queue The driver still needs to map the addresses of memory from their *real* locations into a "window" in it's 2GB of kernel VA (drivers loaded in kernel load in the kernel's VA, and still need to use the AWE APIs to do this). You don't get a free lunch just because you're a driver or a RAMDISK. It's likely the RAMDISK is not going to suffer a noticeable perf hit when using / accessing the swapfile via the driver because it would be a kernel-mode filter driver, hence mapped into nonpaged kernel pool, and thus everything it does is going to be done from RAM . In the 32bit (x86) world, even as a driver, you still have to use the AWE APIs to map and manage those RAM addresses - the memory manager for the OS won't help you. I really cannot explain this at a lower level, as you're getting into core memory manager code, and architectural limitations on the x86 instruction set. If you want to know more, I highly recommend Windows Internals 4th Edition from Mark Russinovich, specifically chapter 7.

It's interesting, yes, and yes you are correct, no one app can use more than 2GB (or 3GB) of RAM, assuming it was using 100% of it's VA and it was 100% mapped into RAM. However, the overhead just isn't worth it, plus the limitation of not being able to execute code there (even the driver would have to move the code down into a window inside the 4GB boundary to execute it like an app would).

Don't confuse virtual memory with actual, physical (RAM) memory. Virtual memory is just that - a virtual construct to map a virtual page that the OS and apps see, and the OS memory manager does all the work of mapping that virtual page address to a *real* memory address backed by *real* pages, either in physical RAM or in the swapfile. The RAMDISK binary is using a driver to handle this, not an application. Drivers can access anything they can be programmed to access, and "hide" things to fool windows on the other end. This is not the same.

Moving to Vista unattend, as this is a more appropriate location for this question.

You can only install a language pack or MUI on an English version of XP Professional, to change it (mostly) to non-English. You cannot take a localized version of XP Professional (say, Turkish) and install any language packs or MUIs on it. If you want English, you need to purchase an English copy of XP.

No, all the old Win9x-era start menu and shell code is finally gone.

Consider creating a hang dump of the iexplore.exe process when it's hung like that, after you navigate to the page but before it displays (and preferably when the CPU and/or memory is showing the consumption patterns you describe). Upload the resulting .dmp files somewhere and we'll take a look.

Yes, trouble, and it has in the past. I'm finishing the work started by the other mods, as your attitude is completely off-base. Anything other than build 7000 was not meant for public release by MS, and as such is warez. If you want to use it or discuss it, do so elsewhere. The continued discussion of this (and your attitude in response to the forum mods) has earned you a ban. In my best Gene Wilder voice, Good day sir.

Whilst you might think that your snark is well placed, remember that this fix was initially introduced in December 1999 for Windows 2000, when the UDMA4 standard was actually ratified. UDMA5 wasn't ratified until early 2002, which was after XP released in October of 2001. Note that at least officially, XPSP1 and up include support for UDMA100 if the chipset drivers allow it, and I don't think that was ever increased when UDMA6 was ratified later in 2005.I don't know why people think this stuff has been around forever, when in reality UDMA4 wasn't ratified until 2000, UDMA5 until 2002, and UDMA6 until 2005.