cluberti

ToonGeneral, any luck after updating the nForce drivers?

Usually, you can tell from the packaging and media. If it's the snazzy Vista box, hologram'ed media, and a product key inside on the case, it's retail. OEM usually doesn't come with anything but a COA sticker and media.

Correct - there's something going on deep inside the audio driver that we can't see here. The sysaudio call is a system call to play a sound on the default sound device, but the heap pointer is invalid. It's not anywhere near the heap ranges in the dump (you can see the ranges with permutations of the !heap command), and if we really are trying to use this heap handle, we're going to bugcheck.

OK, so it's not malware or a virus. It's your audio driver (looks like nForce drivers...). Here's what I've found: //First, the stack causing the problem kd> kvn # ChildEBP RetAddr Args to Child 00 ab5e4b3c 806ee2dc badb0d00 00000000 ab5e4bb0 nt!KiTrap0E+0x233 (FPO: [0,0] TrapFrame @ ab5e4b3c) 01 ab5e4bac 804e4939 00000000 00000000 89b0ce00 hal!KfLowerIrql+0xc (FPO: [0,0,0]) 02 ab5e4bc0 804e68da 00000000 00000001 00000000 nt!KeReleaseMutant+0xbb (FPO: [Non-Fpo]) 03 ab5e4bd8 b9948fd7 b9948eb8 00000000 8a3799a0 nt!KeReleaseMutex+0x14 (FPO: [Non-Fpo]) 04 ab5e4c24 b9fb0f85 8a1849d8 89b0ce00 ab5e4c58 sysaudio!CFilterInstance::FilterDispatchIoControl+0x43 (FPO: [Non-Fpo]) 05 ab5e4c34 804e37f7 8a1849d8 89b0ce00 806ee2d0 ks!DispatchDeviceIoControl+0x28 (FPO: [Non-Fpo]) 06 ab5e4c44 8056a101 89b0cf48 89b0ae78 89b0ce00 nt!IopfCallDriver+0x31 (FPO: [0,0,0]) 07 ab5e4c58 80579a8a 8a1849d8 89b0ce00 89b0ae78 nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo]) 08 ab5e4d00 8057bfa5 0000034c 000002c0 00000000 nt!IopXxxControlFile+0x611 (FPO: [Non-Fpo]) 09 ab5e4d34 804de7ec 0000034c 000002c0 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo]) 0a ab5e4d34 7c90eb94 0000034c 000002c0 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ ab5e4d64) 0b 0012a518 7c90d8ef 7c8016be 0000034c 000002c0 ntdll!KiFastSystemCallRet (FPO: [0,0,0]) 0c 0012a51c 7c8016be 0000034c 000002c0 00000000 ntdll!ZwDeviceIoControlFile+0xc (FPO: [10,0,0]) 0d 0012a57c 73f1228a 0000034c 002f0003 0012a5e4 kernel32!DeviceIoControl+0x78 (FPO: [Non-Fpo]) 0e 0012a5b4 73f149d4 0000034c 002f0003 0012a5e4 dsound!PostDevIoctl+0x6e (FPO: [Non-Fpo]) 0f 0012a604 73f156a7 0000034c 00000002 00000012 dsound!KsGetPinProperty+0x4b (FPO: [Non-Fpo]) 10 0012a638 73f158c3 0000034c 00000012 00000002 dsound!KsIsUsablePin+0x23 (FPO: [Non-Fpo]) 11 0012a66c 73f1cd7f 0000034c 00000001 019021d4 dsound!KsEnumDevicePins+0x8d (FPO: [Non-Fpo]) 12 0012a694 73f4f5f3 03902aa8 01902aa8 019020f0 dsound!CKsDevice::Initialize+0x7a (FPO: [Non-Fpo]) 13 0012a6ac 73f1d6d2 01902aa8 00000000 019021f0 dsound!CKsCaptureDevice::Initialize+0x18 (FPO: [Non-Fpo]) //We know the bugcheck was a STOP 0xA, so analyze -v gives us the arguments we need to troubleshoot: Arguments: Arg1: fffe4080, memory referenced Arg2: 00000002, IRQL Arg3: 00000001, value 0 = read operation, 1 = write operation Arg4: 806ee2dc, address which referenced memory //We know that we were at IRQL Dispatch, and we were doing a write operation (writing to a memory page). Since we bugchecked, and it was a write, it likely means that something accessed memory that had (for whatever reason) been paged out. Like I said before, anything that causes a scheduler event (like a soft page fault to page in memory from the paging file) causes a STOP 0xA at IRQL2 or higher. Let's check this out, then, and look for a page fault: //First, the referenced address is clean, so no problems there (we haven't written yet, and there is nothing here currently - this shouldn't cause an error): kd> dd fffe4080 fffe4080 ???????? ???????? ???????? ???????? fffe4090 ???????? ???????? ???????? ???????? fffe40a0 ???????? ???????? ???????? ???????? fffe40b0 ???????? ???????? ???????? ???????? fffe40c0 ???????? ???????? ???????? ???????? fffe40d0 ???????? ???????? ???????? ???????? fffe40e0 ???????? ???????? ???????? ???????? fffe40f0 ???????? ???????? ???????? ???????? //Next, let's check the address that referenced this memory: kd> uf 806ee2dc hal!KfLowerIrql: 806ee2d0 33c0 xor eax,eax 806ee2d2 8ac1 mov al,cl 806ee2d4 33c9 xor ecx,ecx 806ee2d6 8a8858e26e80 mov cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax] 806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx 806ee2e2 a18000feff mov eax,dword ptr ds:[FFFE0080h] 806ee2e7 c3 ret //So we know we wrote during a KfLowerIrql call. Going back to the Followup IP data, to see what should be pushed back once we lower the IRQL: sysaudio!CFilterInstance::FilterDispatchIoControl+43 b9948fd7 8b75e4 mov esi,dword ptr [ebp-1Ch] //Checking registers to see if ebp-1C is correct in the esi register, and if so, what it points to: kd> r eax=ffdff13c ebx=00000002 ecx=00000000 edx=40000000 esi=806ee2dc edi=fffe4080 eip=804e187f esp=ab5e4b24 ebp=ab5e4b3c iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286 nt!KiTrap0E+0x233: 804e187f f7457000000200 test dword ptr [ebp+70h],20000h ss:0010:ab5e4bac=00010246 kd> r esi esi=806ee2dc kd> r ebp ebp=ab5e4b3c kd> ?1c Evaluate expression: 28 = 0000001c kd> ?ab5e4b3c-0000001c Evaluate expression: -1419883744 = ab5e4b20 kd> dd ab5e4b20 ab5e4b20 804e187f 0000000a fffe4080 00000002 ab5e4b30 00000001 806ee2dc ab5e4b3c ab5e4bc0 ab5e4b40 806ee2dc badb0d00 00000000 ab5e4bb0 ab5e4b50 b9fb0e98 89b0ce00 89aa4f88 b9fb0dbf ab5e4b60 00000000 00000000 89b0ce00 00000000 ab5e4b70 00000023 00000023 00000000 00000000 ab5e4b80 00000000 00000020 ab5e4c14 00000030 ab5e4b90 8a379790 b9948eb8 89b0ce00 ab5e4bc0 kd> dc 804e187f 804e187f 007045f7 74000200 143d830d 0080552a .Ep....t..=.*U.. 804e188f fe69850f 3d83ffff 805593a0 5c850f00 ..i....=..U....\ 804e189f 83fffffe 559e203d 850f0080 fffffe4f ....= .U....O... 804e18af 0000ffb8 a1a8eb00 ffdff054 f05405c7 ........T.....T. 804e18bf 0000ffdf 45890000 e9e58b68 ffffd78d .......Eh....... 804e18cf 7045f790 00020000 45f70d75 0000016c ..Ep....u..El... 804e18df f9840f00 0f000000 210fc321 d7210fc9 ........!..!..!. 804e18ef 89185d89 7d891c4d db210f20 0ff1210f .]..M..} .!..!.. kd> u 804e187f nt!KiTrap0E+0x233: 804e187f f7457000000200 test dword ptr [ebp+70h],20000h 804e1886 740d je nt!KiTrap0E+0x249 (804e1895) 804e1888 833d142a558000 cmp dword ptr [nt!KeI386VdmIoplAllowed (80552a14)],0 804e188f 0f8569feffff jne nt!KiTrap0E+0xb2 (804e16fe) 804e1895 833da093558000 cmp dword ptr [nt!KiFreezeFlag (805593a0)],0 804e189c 0f855cfeffff jne nt!KiTrap0E+0xb2 (804e16fe) 804e18a2 833d209e558000 cmp dword ptr [nt!KiBugCheckData (80559e20)],0 804e18a9 0f854ffeffff jne nt!KiTrap0E+0xb2 (804e16fe) //So, looks like we are pointing correctly - to the KeTrapOE pointer. That means the problem happened at or around the sysaudio!CFilter location in the stack. Let's see what's missing there, if anything: kd> uf 8a1849d8 No code found, aborting kd> dc 8a1849d8 8a1849d8 00c40003 00000000 8a2bac10 00000000 ..........+..... 8a1849e8 00000000 00000000 00000000 00002050 ............P .. 8a1849f8 00000000 00000000 8a184a90 0000002f .........J../... 8a184a08 00000007 00000000 00000000 00000000 ................ 8a184a18 00000000 00000000 00000000 00000000 ................ 8a184a28 00000000 00000000 00000000 00000000 ................ 8a184a38 00140014 8a184a3c 8a184a3c 00000000 ....<J..<J...... 8a184a48 00000000 00000000 00000000 00000000 ................ kd> !heap 00c40003 Index Address Name Debugging options enabled kd> !address 00c40003 address 00c40003 not found in any known Kernel Address Range ---- kd> uf 00c40003 No code found, aborting kd> ln 00c40003 kd> dc 00c40003 00c40003 ???????? ???????? ???????? ???????? ???????????????? 00c40013 ???????? ???????? ???????? ???????? ???????????????? 00c40023 ???????? ???????? ???????? ???????? ???????????????? 00c40033 ???????? ???????? ???????? ???????? ???????????????? 00c40043 ???????? ???????? ???????? ???????? ???????????????? 00c40053 ???????? ???????? ???????? ???????? ???????????????? 00c40063 ???????? ???????? ???????? ???????? ???????????????? 00c40073 ???????? ???????? ???????? ???????? ???????????????? I can't say for sure what this is, but 00c40003 certainly looks like a heap location (but not in any active heaps for this process). I also don't know for sure why it's being called, but I can say it's empty and invalid (and would generate a page fault when hit, and ultimately a STOP 0xA). If you would, upgrade your nForce driver set to the latest WHQL or WDDL version (if available) from NVidia, and see if that helps.

Does the machine boot in safe mode at all?

Run replmon and force a replication, and that should show you if it's actually working or not - and if not, why.

These aren't even kernel dumps, they're "small" dumps, so this does change things. We will need at least a kernel dump (and a full dump, if you can get it). Here's what I can tell, at least, from the data I've got - every dump eventually shows that we're failing in a kernel-mode driver that is trying to write to a memory page that has not been allocated or initialized, but these writes are while whatever driver is causing this is at IRQ Level (IRQL) 2. That's important because anything running at L2 or higher cannot cause a fault that will invoke the scheduler, and page faulting on either a paged-out memory address to copy back into memory, or writing to an unallocated or uninitialized block, will do exactly that). When this happens, the box immediately bugchecks, because this is a no-no. In each dump, every time we're either pointing to memory or accessing memory where a kernel-mode driver object should be, and it seems like either the nForce chipset drivers are at fault here, or your box might be running some sort of malware or rootkit - those are the only times I see this. Again, we need at least a kernel dump, and a full dump if you can, in order to narrow this down further. That said, here's what I've found so far, for reference. All of the dumps you have basically look like this once taken apart, but they're all faulting in different kernel-mode modules, making me suspicious of possible malware (I'm somewhat paranoid about random bugchecks, you see, and these are all random enough to trigger my paranoia): //Here, we see the stack at the time of the fault: kd> kvn # ChildEBP RetAddr Args to Child 00 f78ced28 804e4939 00000000 8a4cb280 8a4cba40 hal!KfLowerIrql+0xc (FPO: [0,0,0]) 01 f78ced3c 804e68da 00000000 00000001 00000000 nt!KeReleaseMutant+0xbb (FPO: [Non-Fpo]) 02 f78ced54 b1ddc0c4 8a4cba40 00000000 8a4cbbbc nt!KeReleaseMutex+0x14 (FPO: [Non-Fpo]) WARNING: Stack unwind information not available. Following frames may be wrong. 03 00000000 00000000 00000000 00000000 00000000 nvapu+0x160c4 //Next, we check to see if we're in kernel mode or user mode: kd> dg nvapu P Si Gr Pr Lo Sel Base Limit Type l ze an es ng Flags ---- -------- -------- ---------- - -- -- -- -- -------- B1DC6000 00000000 ffffffff Code RE Ac 0 Bg Pg P Nl 00000c9b //The PL number is 0 (hard to see here, but it is), which means the cs register tells us we're in kernel mode //Let's look at the registers for the KfLowerIrql frame: kd> r eax=00000000 ebx=8a4cba00 ecx=00000000 edx=00000000 esi=8a4cba40 edi=8abf5b30 eip=806ee2dc esp=f78ced2c ebp=f78ced3c iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210246 hal!KfLowerIrql+0xc: 806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx ds:0023:fffe0080=???????? //cs says we've got full privs, and all registers seem to be OK, so let's unassemble this: kd> u hal!KfLowerIrql hal!KfLowerIrql: 806ee2d0 33c0 xor eax,eax 806ee2d2 8ac1 mov al,cl 806ee2d4 33c9 xor ecx,ecx 806ee2d6 8a8858e26e80 mov cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax] 806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx 806ee2e2 a18000feff mov eax,dword ptr ds:[FFFE0080h] 806ee2e7 c3 ret hal!KeGetCurrentIrql: 806ee2e8 a18000feff mov eax,dword ptr ds:[FFFE0080h] //We know that the address that referenced the memory was 806ee2dc from the bugcheck code, so that means that this is the instruction we were executing when we bugchecked: 806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx //According to IA32 processor Spec, FFFE0080 is the address of TPR register of Local APIC, NT uses TPR to manage its own interrupt priority which is independent of hardware priority. From what I can tell, we're done lowering the IRQ Level and are finishing cleaning up our locals and variables: kd> x nt!K*Apc* 804e5287 nt!KeInitializeApc = <no type information> 80516463 nt!KeAreApcsDisabled = <no type information> 805593f8 nt!KeUserApcDispatcher = <no type information> 804e5411 nt!KeInsertQueueApc = <no type information> 804f9ea4 nt!KeDisableApcQueuingThread = <no type information> 80533f6a nt!KeVdmInsertQueueApc = <no type information> 8050692d nt!KeRemoveQueueApc = <no type information> 804db828 nt!KiSwapContext = <no type information> 804eb869 nt!KiMoveApcState = <no type information> 804e5379 nt!KiInsertQueueApc = <no type information> 804e61f4 nt!KiInitializeUserApc = <no type information> 804e52dd nt!KiDeliverApc = <no type information> 804f9e3a nt!KeFlushQueueApc = <no type information> kd> dt nt!_KAPC +0x000 Type : Int2B +0x002 Size : Int2B +0x004 Spare0 : Uint4B +0x008 Thread : Ptr32 _KTHREAD +0x00c ApcListEntry : _LIST_ENTRY +0x014 KernelRoutine : Ptr32 +0x018 RundownRoutine : Ptr32 +0x01c NormalRoutine : Ptr32 +0x020 NormalContext : Ptr32 Void +0x024 SystemArgument1 : Ptr32 Void +0x028 SystemArgument2 : Ptr32 Void +0x02c ApcStateIndex : Char +0x02d ApcMode : Char +0x02e Inserted : UChar kd> dt nt!_KTHREAD +0x000 Header : _DISPATCHER_HEADER +0x010 MutantListHead : _LIST_ENTRY +0x018 InitialStack : Ptr32 Void +0x01c StackLimit : Ptr32 Void +0x020 Teb : Ptr32 Void +0x024 TlsArray : Ptr32 Void +0x028 KernelStack : Ptr32 Void +0x02c DebugActive : UChar +0x02d State : UChar +0x02e Alerted : [2] UChar +0x030 Iopl : UChar +0x031 NpxState : UChar +0x032 Saturation : Char +0x033 Priority : Char +0x034 ApcState : _KAPC_STATE +0x04c ContextSwitches : Uint4B +0x050 IdleSwapBlock : UChar +0x051 Spare0 : [3] UChar +0x054 WaitStatus : Int4B +0x058 WaitIrql : UChar +0x059 WaitMode : Char +0x05a WaitNext : UChar +0x05b WaitReason : UChar +0x05c WaitBlockList : Ptr32 _KWAIT_BLOCK +0x060 WaitListEntry : _LIST_ENTRY +0x060 SwapListEntry : _SINGLE_LIST_ENTRY +0x068 WaitTime : Uint4B +0x06c BasePriority : Char +0x06d DecrementCount : UChar +0x06e PriorityDecrement : Char +0x06f Quantum : Char +0x070 WaitBlock : [4] _KWAIT_BLOCK +0x0d0 LegoData : Ptr32 Void +0x0d4 KernelApcDisable : Uint4B +0x0d8 UserAffinity : Uint4B +0x0dc SystemAffinityActive : UChar +0x0dd PowerState : UChar +0x0de NpxIrql : UChar +0x0df InitialNode : UChar +0x0e0 ServiceTable : Ptr32 Void +0x0e4 Queue : Ptr32 _KQUEUE +0x0e8 ApcQueueLock : Uint4B +0x0f0 Timer : _KTIMER +0x118 QueueListEntry : _LIST_ENTRY +0x120 SoftAffinity : Uint4B +0x124 Affinity : Uint4B +0x128 Preempted : UChar +0x129 ProcessReadyQueue : UChar +0x12a KernelStackResident : UChar +0x12b NextProcessor : UChar +0x12c CallbackStack : Ptr32 Void +0x130 Win32Thread : Ptr32 Void +0x134 TrapFrame : Ptr32 _KTRAP_FRAME +0x138 ApcStatePointer : [2] Ptr32 _KAPC_STATE +0x140 PreviousMode : Char +0x141 EnableStackSwap : UChar +0x142 LargeStack : UChar +0x143 ResourceIndex : UChar +0x144 KernelTime : Uint4B +0x148 UserTime : Uint4B +0x14c SavedApcState : _KAPC_STATE +0x164 Alertable : UChar +0x165 ApcStateIndex : UChar +0x166 ApcQueueable : UChar +0x167 AutoAlignment : UChar +0x168 StackBase : Ptr32 Void +0x16c SuspendApc : _KAPC +0x19c SuspendSemaphore : _KSEMAPHORE +0x1b0 ThreadListEntry : _LIST_ENTRY +0x1b8 FreezeCount : Char +0x1b9 SuspendCount : Char +0x1ba IdealProcessor : UChar +0x1bb DisableBoost : UChar kd> dt nt!_KAPC_STATE +0x000 ApcListHead : [2] _LIST_ENTRY +0x010 Process : Ptr32 _KPROCESS +0x014 KernelApcInProgress : UChar +0x015 KernelApcPending : UChar +0x016 UserApcPending : UChar kd> uf 806ee2dc hal!KfLowerIrql: 806ee2d0 33c0 xor eax,eax 806ee2d2 8ac1 mov al,cl 806ee2d4 33c9 xor ecx,ecx 806ee2d6 8a8858e26e80 mov cl,byte ptr hal!HalpIRQLtoTPR (806ee258)[eax] 806ee2dc 890d8000feff mov dword ptr ds:[0FFFE0080h],ecx 806ee2e2 a18000feff mov eax,dword ptr ds:[FFFE0080h] 806ee2e7 c3 ret kd> dt nt!_KPROCESS +0x000 Header : _DISPATCHER_HEADER +0x010 ProfileListHead : _LIST_ENTRY +0x018 DirectoryTableBase : [2] Uint4B +0x020 LdtDescriptor : _KGDTENTRY +0x028 Int21Descriptor : _KIDTENTRY +0x030 IopmOffset : Uint2B +0x032 Iopl : UChar +0x033 Unused : UChar +0x034 ActiveProcessors : Uint4B +0x038 KernelTime : Uint4B +0x03c UserTime : Uint4B +0x040 ReadyListHead : _LIST_ENTRY +0x048 SwapListEntry : _SINGLE_LIST_ENTRY +0x04c VdmTrapcHandler : Ptr32 Void +0x050 ThreadListHead : _LIST_ENTRY +0x058 ProcessLock : Uint4B +0x05c Affinity : Uint4B +0x060 StackCount : Uint2B +0x062 BasePriority : Char +0x063 ThreadQuantum : Char +0x064 AutoAlignment : UChar +0x065 State : UChar +0x066 ThreadSeed : UChar +0x067 DisableBoost : UChar +0x068 PowerState : UChar +0x069 DisableQuantum : UChar +0x06a IdealNode : UChar +0x06b Flags : _KEXECUTE_OPTIONS +0x06b ExecuteOptions : UChar kd> r al al=0 kd> r cl cl=0 kd> u 806ee258 hal!HalpIRQLtoTPR: 806ee258 003d41415161 add byte ptr ds:[61514141h],bh 806ee25e 7181 jno hal!PicHandler+0x135 (806ee1e1) 806ee260 91 xchg eax,ecx 806ee261 a1b1b1b1b1 mov eax,dword ptr ds:[B1B1B1B1h] 806ee266 b1b1 mov cl,0B1h 806ee268 b1b1 mov cl,0B1h 806ee26a b1b1 mov cl,0B1h 806ee26c b1b1 mov cl,0B1h So it looks like we've walked back to zero, and are either calling back into the driver, or trying to write to an address that is invalid (not likely). We need more data!

1. Use the snipping tool to take screenshots - it's pretty nifty, and you can find it by typing in "snip' in the search box under the "start" button 2. In Task Manager, with the "Processes" tab selected, you can click View > Select Columns and add those two colunm headers (which you can then sort by just by clicking on the column in Task Manager).

Sounds like you're either running too many apps, or have a driver causing a memory leak (if you've installed any, using non-Vista drivers are notorious for this, especially Audio drivers). Could you perhaps run a perfmon, gathering all of the "Process" counter objects for everything on the box? Even just a screenshot of the Processes tab from Task Manager when you're really high would help, assuming you've added the "Memory - Working Set" and "Memory - Private Working Set" columns to the display (sort by the working set column, snapshot, then sort by the private working set column and snapshot).

Actually, for this error, a kernel dump will do. ToonGeneral, do you still have the kernel dump? I'd like to look at it.

Boot from your Windows XP media, and press "R" when prompted to do a repair from the recovery console. Log into the recovery console with the admin password for your installation of Windows, then run the "fixboot" command. Run the "exit" command to reboot, and things should be fixed there as well.

I've always considered a "major" app release to be a full dot release (1.0, 2.0, etc). If I feel that the application has enough new or changed functionality, or I've quashed a large number of bugs since the last release (or both), I consider it a major release. A small feature update or change release is generally a point release (1.x, 2.x, etc), and a bugfix-only release is generally the point+n release (1.x.n, 2.x.n, etc). It's generally whatever you want to do - there are no hard and fast rules (although there are some general consensus) as to how you work with your applications.

Now THAT'S a funny one I've not heard before - bravo

Yes, you'll need the x64 version for XP. As to the 404s, it's going to be load-related. I'd say keep trying, and you'll get a download slot eventually .

Have you considered searching through the sections in group policy for modifying the behavior of Internet Explorer?

You either have (or had) a bad install of IE7, or have an IE7 beta installed - if so, uninstall IE7 (revert back to IE6) and see if the error has gone. If you've already uninstalled, and the error still occurs, run the following command, then REBOOT the PC rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 c:\windows\inf\ie.inf *** remember to reboot! *** Once you've rebooted, the error should go away when attempting to browse with IE. If you want, you can reinstall IE7 and it should work properly.

No, it does not. However, it does include: - icacls.exe, replaces cacls.exe - XmlLite XML parser - Scalable Networking Pack - updates any RIS installs to WDS - allows new Firewall per port authentication - MMC 3.0 - WPA2 support - allows install of updated MUI packs - msconfig changes (scans for more installed apps and services) - better IPSec filter management - larger default store for MSMQ (1GB) - New cluster service account events for the event log (more information, more granular) - updated dcdiag allowing additional DNS tests - other performance improvements specifically for SQL servers and Windows Virtualization

You are missing a VERY IMPORTANT distinction between the car and Windows - you are buying the car, but you aren't buying Windows at all. You are buying a LICENSE to USE Windows, and you don't own the source code or the actual OS binaries - nor can you legally do whatever you want with them (including bypass things like security mechanisms and built-in limitations, unless the methods or mechanisms to do so are provided you by Microsoft or an agent thereof). Therefore, at least in the US and certain other countries, you can indeed be legally limited in usage and functionality by the owner of the product you've licensed in almost any way they see fit (read that EULA you clicked yes to when you powered on your machine or agreed to when you installed Windows). You're comparing apples to oranges in the car vs Windows analogy, and unfortunately for you if you don't like this arrangement your other options are open source or open source. Note that you get the same sort of EULA when you purchase MacOS - you don't own that either, and are under similar obligations and rights from Apple.

Yes, it's real. Today is RTW for W2K3 SP2. And it's unavailable because the servers are being hammered - if you can't get the express package, you may be able to download the full package (it'll take a bit longer, but you'll at least be able to get it).

What is the error? Do you get a "page could not be displayed" error, and is it right away, or does it take 10 - 15 seconds to occur?

Darn it - I thought I had linked the KB. Regardless, the error you're getting means you're running out of some kernel resource (and if you're file copying, it's almost always kernel paged pool). Do you see any 2020 events in your system event log?

All time in the OS is based on UTC, and the OS uses the DST registry data to determine what the "local" time is. Thus, the time you see is actually correct, but your "window" into the local time via the DST data in your registry on the workstations is what is causing the hour off - the servers have likely updated for DST, but the clients still are operating on the old rules.

I was actually about to suggest that one to you yesterday, but got distracted elsewhere. It actually does generally help when things like this happen, as it can alleviate race conditions where logon scripts or startup scripts are running while networking is also coming up.

The only problem with testing in general, including tests like the *AT tests, is that they test on the basis of what you should have learned over your years in grammar and secondary school, rather than what you're capable of (some would consider this IQ) - not to mention that the tests are skewed towards secondary school students, as that is the required age and grade range to take almost all of the possible *AT tests (in the US). Almost anyone with a decent IQ and work ethic can study and do very well on a test, but only a few of those people can actually be given a problem scenario or task and figure it to it's conclusion. Logic tests like an IQ test pursue this somewhat, but they are still weighted by age and rely on a "one correct answer" test methodology, which can skew results somewhat. How many things in life are actually black and white, even in things like math, science, history, and language (latin notwithstanding)? Is this really a valid test scenario to judge "intelligence"? </sarcasm> Case in point - I love seeing these TV specials (here in the US) where they put an adult of 30 or 40 against a schoolchild on a math or science exam, and the schoolchild scores higher (sometimes much higher) than the adult - and the claim is made that adult is not as smart as the child, because the child scored higher on a standardized test. Notwithstanding the fact that I am sure some of us may personally know adults that actually *are* less intelligent than most smart schoolchildren out there , but let's call a spade a spade - the child does better because he's actively studying most of the things tested on, whereas the adult hasn't touched the stuff in 20 - 30 years (and unless he actually uses that math or science for his or her job, likely never will again). Does this make the child smarter than the adult? Or does it reinforce the idea that studying for tests and taking them is a less effective way to actually learn (as we see by the adult not remembering anything he "learned" as a child)? How many of us, who consider ourselves intelligent and smart, remember most of what we learned in grammar and secondary school? Or even college or University? If used on a daily basis, then yes, the knowledge is likely maintained - however, for the bulk of us who never really use any of the knowledge gained in gradeschool and secondary schools, the answer to that is probably little to none. I will agree that forcing children to "learn" is a great way for most to boost intelligence and troubleshooting/problem-solving skills they'll need later in life, but as it's used nowadays to judge intelligence and "smarts", does a disservice to learning institutions everywhere (see the results of the "no child left behind act" on our US schoolsystems and schoolchildren today - ask the teachers specifically). /me gets off soapbox

Exactly. But they shouldn't advertize it as a security enhancement. GL Well, I think you're thinking of the limit on OUTBOUND incomplete connections., which is a security enhancement - if not for the user themselves. for the rest of us. There is a limit on COMPLETE outbound connections, but it's around 65,000, and that's actually a 32bit limitation, rather than a Windows limitation. The 10 connections I was referring to was the 10 INBOUND connection limit, which is designed to get people to purchase a server product for a machine hosting more than 10 inbound connections. The OP (melodylife) did not specify inbound or outbound, so I assumed outbound as the OP did not specifically state that this was about incomplete outbound connections, but connections in general. In short, there are limitations in Windows client OSes on inbound and outbound connections: - 10 incoming connections, always enforced - 10 outbound connections, when connections are considered "incomplete" (half-open) - 65,536 outbound connections, when connections are considered "complete"