cluberti

Actually, this is one where the bugcheck description is probably enough to determine the problem: Bug Check 0x116: VIDEO_TDR_ERROR The VIDEO_TDR_ ERROR bug check has a value of 0x00000116. This indicates that an attempt to reset the display driver and recover from a timeout failed. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 The pointer to the internal TDR recovery context, if available. 2 A pointer into the responsible device driver module (for example, the owner tag). 3 The error code of the last failed operation, if available. 4 Reserved. I'd say you've got a video driver problem...

Do not double post.

Well, technically you wouldn't remove it, per se, but you could conceivably replace the file(s) on the SP3 disk with SP2 versions. Does this happen if you install XP (either RTM or SP2) and upgrade to SP3?

DNS proxying to that site would be done either on your box directly, or upstream via an attack on your ISPs DNS servers (both are extremely possible). However, I've used nLite and vLite for quite some time now (nLite for years), and this is not something done by this product. You should probably run a scan on your machine for malware and viruses, or, contact your ISP about "dns poisoning" (and if they don't know what you're talking about, consider another ISP ).

Svchost.exe is just a container process for things to run in, and as you have already noticed you have quite a few of these running. I would strongly suggest Process Explorer to take a look at what is running inside the offending svchost, because there can be any number of things causing this. Svchost.exe is used by a lot of malware (because you have quite a few that are normally listed and running critical services, so it makes it easier to hide inside a svchost because you already expect to see that in a process list). Process Explorer will show you what's running inside of it if you hover over the item in the process list, and also show you what inside of it is consuming CPU. Knowing you have a C:\Setup.exe on the box, I'm quite suspicious of what's going on in there.

SMSS.exe (the process that is failing, causing the bugcheck) is the process that is required to start all other user-mode processes on the system, and this loads immediately after the kernel to get Windows running. Those two error codes are supposed to provide valid data on the error, but since they're both 0x0 it's almost completely useless. Does this happen on every reboot after install? If so, you need to try installing with a clean source (if you haven't already) to make sure it works. Otherwise, it's something with nLite and you might want to try doing it again. This bugcheck is pretty much death, meaning you either remove whatever it is you just installed before the reboot, or, during a Windows install, you have to start over.

Certificates are not in the realm of IE or IIS, technically, they're handled by security.dll and the schannel.dll crypto APIs of the OS itself. You might want to get some schannel logging going on the server AND the client to see what is actually happening under the 403.7...

This is ridiculous... SP3 obviously breaks folder redirection and Microsoft will not admit to it. I've been on the phone with Microsoft for over 25 hours this week and have got nowhere. I was able to find a temporary workaround for it though. If you replace the current %system32%\fdeploy.dll (version 5.1.2600.5512) in SP3 with the one included in SP2 (version 5.1.2600.2180), folder redirection in SP3 will work if you are having problems with it. Nate Ask to be escalated to premier support

One question - are you using iexplore.exe*32 (32bit), or the 64bit iexplore.exe?

There really shouldn't be. If you want to continue using NOD32 or Kerio PF, you'll need 64bit versions (they use filter drivers, and you have to use 64bit filter drivers on an x64 box) - however, I don't see anything else there that would suggest fail on x64 from your list, and anything that truly fails can always be run in a VM . Seriously, other than antivirus and firewall needing to be x64, the others should work just fine as 32bit apps under Wow64.

Yessir.

Well, most of your programs technically should work, unless they use 32bit drivers, require AWE API access (can't imagine most userland apps will), or have specific requirements for an OS check or will completely fail the new security or registry/file virtualization model in Vista. There are a few games I'm aware of that won't work, along with potential issues with some Adobe apps. What kinds of apps are you thinking about using?

Well I found out the problem was SP1 afterall. I reformatted and reinstalled and I've got all the updates and patches along with all suspect programs. SP1 was the offender. I just d/led the good hotfixes from SP1 without actually d/ling SP1 now and all is well again. Apparently SP1 isn't ready for public use yet! You're the first person I've heard of having this issue with SP1, so I'm not sure your assessment is accurate about it not being ready, but it is possible one of the hotfixes that isn't GDR but included in SP1 could cause it. If you're reinstalling, what happens if you install an actual SP1 copy of Vista?

Ouch, hate to say it but this isn't useful... 1: kd> kb RetAddr : Args to Child : Call Site fffff800`01cb112e : 00000000`0000000a 00000000`00000008 00000000`0000000c 00000000`00000001 : nt!KeBugCheckEx fffff800`01cb000b : 00000000`00000001 fffffa80`0a8cf700 fffffa80`0a8cf700 fffffa80`0a7392a0 : nt!KiBugCheckDispatch+0x6e fffff800`01cb7509 : 00000000`00395870 00000000`00000000 fffffa80`0a6fcaf0 00000000`00000000 : nt!KiPageFault+0x20b Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details fffff960`0018b7c6 : fffffa80`0a83ec10 00000000`00000000 fffffa80`0a8cf700 fffff800`01f4c5f1 : nt!KeSetEvent+0x289 Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details fffff960`0018d7d9 : 00000000`0000c046 fffff900`c1fad4f0 fffff900`c1fad860 fffff960`00187468 : win32k!SetWakeBit+0xe6 Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details fffff960`0018d5c0 : 00000000`0000c046 00000000`00000000 fffff900`c1fad860 fffff900`c1fad4f0 : win32k!_PostThreadMessage+0x151 Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details Page a0125 not present in the dump file. Type ".hh dbgerr004" for details fffff800`01cb0e33 : fffffa80`0a8cf700 fffffa60`0d812ca0 00000000`0041c9c0 00000000`0041c9c0 : win32k!NtUserPostThreadMessage+0x25c Page a0125 not present in the dump file. Type ".hh dbgerr004" for details 00000000`774934ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x774934ba If you can set your page file size on C: to have both the Min and Max values be 6144, reboot, and try again - this dump is missing a LOT of information, especially about the callstack where the problem occurred (not good).

Server Core, TS Gateway, TS App Publishing, Hyper-V Clustering, Read-Only domain controllers, ADFS/ADCFS, WDS in multicast, NAP for clients to start (all of which I use heavily).

Hm - c0000005 means "Access Denied" - perhaps a process monitor log of the app starting would show you the Access Denied? Otherwise you'll need to get a dump of wmp starting.

Well, the minidump did give something, which was surprising in and of itself. I've got the bugcheck and exception record, and I think maybe this is a driver problem (although getting that full memory.dmp uploaded somewhere to make sure is still prudent). Here's what I see: 1: kd> .bugcheck Bugcheck code 0000000A Arguments 00000000`00000008 00000000`0000000c 00000000`00000001 fffff800`01cb7509 // looks like we have (potentially) tried to move the contents of rax into 0x8, which of // course will fail: 1: kd> .trap 0xfffffa600d812940 NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffffa800a416618 rbx=fffffa600d812a98 rcx=0000000000000000 rdx=fffffa8005f8f8c0 rsi=fffffa8000000000 rdi=2000000070000000 rip=fffff80001cb7509 rsp=fffffa600d812ad0 rbp=fffffa800a7392a8 r8=0000000000000000 r9=0000000000000000 r10=fffff9600018d364 r11=fffff900c1fad4f0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc nt!KeSetEvent+0x289: fffff800`01cb7509 48894108 mov qword ptr [rcx+8],rax ds:00000000`00000008=???????????????? // we were working with the win32k queue structure, and we were involved in drawing // something in the window for taskeng.exe (the task manager): 1: kd> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site fffffa60`0d812ad0 fffff960`0018b7c6 nt!KeSetEvent+0x289 fffffa60`0d812b40 fffff960`0018d7d9 win32k!SetWakeBit+0xe6 fffffa60`0d812b70 fffff960`0018d5c0 win32k!_PostThreadMessage+0x151 fffffa60`0d812bd0 fffff800`01cb0e33 win32k!NtUserPostThreadMessage+0x25c fffffa60`0d812c20 00000000`774934ba nt!KiSystemServiceCopyEnd+0x13 00000000`038de378 00000000`00000000 0x774934ba This could be a malfunctioning device driver (in fact, it almost always is when win32k.sys is involved in the crash), but we'll wait for the full dump to be sure. I've seen overclocked machines do this, I've seen bad RAM cause this, and I've seen hard drives that are dying cause this as well, so I need to be sure before I blame anything software.

JedMeister is correct - without knowing what that bluescreen is about makes this a guessing game.

If you have any drivers or apps that hold handles open to a user's registry hive, then yes, it's still recommended. However, if you don't see uphclean errors in the event log when users log on and off, you don't need it.

The color? Not sure, but what color are we talking about?

winnt.sif should be in the \i386 folder.

When it's done, change it back

Correct, it's not running Linux anymore (so no upgrade).

What linksys router are you using, and what revision number is it (should say on the bottom)?

Technet already has a really good doc on setspn, so I'll link it.