cluberti

Well, hope eseutil works then - otherwise, you're starting over.

Tell me you have a backup... otherwise, you're in hot water. You can try running ESENTUTL /g "<path>\NTDS.dit" /!10240 /8 /v /x /o and then run an integrity check on the files, and a semantic database analysis, which should hopefully work - if they do, you should be able to reboot the DC properly, but there will be problems with the DC's database and you may still have lingering issues. Honestly, if that works, consider yourself lucky - bring up a new domain controller, make it a global catalog server, move the FSMO roles onto it, and dcpromo this failed server down to a member server. Then, rebuild it and add it back to the domain and dcpromo it to a DC/GC server as well, and LEAVE THEM BOTH UP AND RUNNING . Never, ever, EVER have a single DC environment unless you are running SBS - and even then, always, ALWAYS back up your DC. Here's the disaster recovery powerpoint - read it http://download.microsoft.com/download/0/3...AD_Disaster.ppt

No problem - understand segmentation completely, but it just won't be possible.

What happens if you configure your WAP to broadcast your SSID, and change security to WEP? Does that change the behavior of the wireless at all? If so, you've got either bad hardware or bad drivers (usually the latter).

ICS cannot share a wireless connection, only wired. If you need to extend your WAP's range, consider Netgear's extender products, since you're already using a Netgear WAP: http://www.netgear.com/Products/PowerlineN...ts/WGXB102.aspx cluberti do you know whats the range limit of the 2 electric outled? i couldnt find it on the specification page.i really like to know how far the outled can be. thanks Actually, I think as long as it's on the same physical circuit, it should be OK (anywhere in your house should be fine, as it'll all be off of the same circuit except maybe your stove if electric and your washer/dryer).

Actually, Vista SP1 severely limited trustedinstaller.exe, so it no longer chews up my CPU. I've been running SP1 for a little while now, so I've not noticed it anymore, but I do remember just disabling WU and the security center popups before SP1.

It was abandoned because someone wrote crappy code, but otherwise I cannot answer that question. Mutexes aren't removed, they're allocated and released - the kernel creates and deletes them (so if one is abandoned, it means a driver didn't free it before it terminated that thread or unloaded itself). Always, yes. To debug you need at least the following: 1. Decent knowledge of C/C++ (and if you're debugging an app written in another language, you need to know that too) - being able to write code is not required, as just reading code is sufficient to do basic debugging. However, being able to write code means you can think in code, which you will have to be able to do when attempting any debug that is above and beyond something easy, like debugging an application crash is easy, but tracking down a system hang or "slowess" in an app or the system is much harder. You also need to be able to understand and follow Intel assembly language as well. 2. Knowledge of memory management, structures, code flow, reading hex, cpu registers and what they are and how they can be populated, heap structures, etc. 3. If you are debugging the Windows kernel, you need to understand how the memory manager works, how the kernel executive works, and a general understanding of how usermode and kernelmode apps, services, and drivers interact. 4. Understand debugging is part science, part art. I would suggest first learning enough C++ to write a basic notepad program, a basic service, and a basic kernel driver. Then, acquire and read the books "Windows Internals, 4th Edition" and "Advanced Windows Debugging". Once you've gone through those books a few times and you've got decent code skills, start trying to debug things on your own machine or from dumps available here to work on your skills. There are classes you can take to learn more about debugging, but you will still be expected to have code, assembly, and basic debug knowledge even for these classes. I don't endorse one school or training center above another, because I've not used any, but I know they're out there.

No, the only way to do this is to make multiple sites. Machines will try to log onto the DC in their site before trying DCs at other sites. Why would logging onto a machine at the other side of the factory make a difference, might I ask?

Umm yeah . If you browse to \\domaincontroller\sysvol\<domain>\policies, and you don't see this folder (worse, if you don't see ANY folders), then your GPOs are gone. Restore from backup .

Is this your only domain controller?

http://www.microsoft.com/windowsserver2003...ks/default.mspx

Windows SteadyState candidate, maybe?

I'd personally blame the Windows Updates service, as it lives in an svchost.exe process and invokes trustedinstaller.exe to scan for updates. If you haven't already, I'd disable that service and only enable it once a month to check for updates, then disable it again.

If a machine has a virus, trojan, malware, what have you - that is suspect until completely removed. So yes, I'd consider it a good possibility. No - the mutex is abandoned, and it's unowned. I can't go back in time and figure it out for sure , so I have to make educated guesses.

If you browse to \\myserver.mydomain.local\sysvol, and go into the policies folder for the domain, do you see a folder called "{62A72F2C-B896-4083-A14B-79808A1D82EE}"? If you browse to \\domain\netlogon and browse into the policies, do you see this folder there as well?

It sounds like either file system corruption, or a hard drive going south (or both). I'd back up data off of that drive and test it with a vendor hard drive test - if the hard disk test passes, then it's just a bum filesystem and a reinstall on that disk should be OK. Either way, consider it a catastrophic failure and boot the machine from a recovery CD to get the data off.

could very well be, but I can't say for sure. The mutex is abandoned, so I have no way of knowing who owned it. The only way to remove kernel-level filter drivers (Spyware Doctor and Acronis) is to uninstall. Disabling user-mode services does nothing to unload kernel drivers, as they load when the kernel does, long before services are even started. As I said, I don't know for sure, but I do know it's network-related. The nvidia driver and Spyware doctor are both network drivers, and the virus could be too. Not sure about the Acronis software, but with a problem like this I like to remove ALL kernel-mode drivers when possible and work back from there.However, if you really do have the virus, I'd just back up data and rebuilt - you'll never be able to be 100% sure that installation of Windows isn't compromised, ever again.

This should work: http://compnetworking.about.com/cs/wireles...buildwlan_4.htm http://www.intel.com/support/wireless/wlan/sb/CS-025386.htm

Honestly, once a machine becomes infected, it is really better to move your data off to another system or, even better, burn to a DVD, and wipe the box and start over.

I'm noticing that you have no gateway set on any of the interfaces - how are any of them going to know how to route to the internet? Also, I'm pretty sure you cannot enable ICS on a wireless connection, even in ad-hoc mode.

Well, I can understand how processes across the whole machine appear to be hanging - it appears something at the kernel level at the network stack is causing this. Here's the bitcomet and msn messenger dumps so you can see how I determined the network stack is at fault: From the bitcomet dump: // There are three critical sections that are locked in this dump, and // the third one in the list is the important one - it's holding everything // else up: 0:000> !locks CritSec +14744f8 at 014744f8 LockCount 0 RecursionCount 1 OwningThread 208 EntryCount 0 ContentionCount 0 *** Locked CritSec +14737b0 at 014737b0 LockCount 0 RecursionCount 1 OwningThread 8a8 EntryCount 0 ContentionCount 0 *** Locked CritSec +1234088 at 01234088 LockCount 1 RecursionCount 1 OwningThread 208 EntryCount 4 ContentionCount 4 *** Locked // The thread owning the critsec is thread 0, so if it's waiting on // something, the whole window or application will appear to hang: 0:000> kb ChildEBP RetAddr Args to Child 0012f4f4 7c90d8ef 71a5da55 000006ac 00000000 ntdll!KiFastSystemCallRet 0012f4f8 71a5da55 000006ac 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc 0012f59c 71a555af 01233ff0 0012f714 00000010 mswsock!SockDoConnectReal+0x1b0 0012f644 71a5542c 000008e0 0012f714 00000010 mswsock!SockDoConnect+0x392 0012f674 71ab40bd 000008e0 0012f714 00000010 mswsock!WSPConnect+0xc6 0012f6c0 0053c485 000008e0 0012f714 00000010 ws2_32!connect+0x4f WARNING: Stack unwind information not available. Following frames may be wrong. 0012f728 0053b7b4 014c59c0 0000c350 aa88f6ba BitComet+0x13c485 0012f7cc 0040826c 00000000 0192a700 007009f2 BitComet+0x13b7b4 0012f854 005bdde5 01473890 0447e080 0447e0b8 BitComet+0x826c 0012f870 005ab2d0 0447e080 0447e0b8 0447e300 BitComet+0x1bdde5 0012f8c4 005617eb 0012f938 aa88f80e 00000000 BitComet+0x1ab2d0 0012f918 005513a9 aa88f8b2 00000000 7c809728 BitComet+0x1617eb 0012f9a4 005bce09 014744a0 014d3db8 00000000 BitComet+0x1513a9 0012f9bc 0045f761 aa88f8de 014d3db8 00000000 BitComet+0x1bce09 0012fae8 00697c52 00000000 aa88fa96 00000113 BitComet+0x5f761 0012fb80 006934f8 00000113 00000000 0082a260 BitComet+0x297c52 0012fba0 0050af0a 00000113 00000000 00000000 BitComet+0x2934f8 0012fc0c 0048396e aa88fd2a 0012fc84 0012fc68 BitComet+0x10af0a 0012fc3c 0050ab14 aa88fd5e 00000113 014d3db8 BitComet+0x8396e 0012fc98 00695e1f 00000113 00000000 00000000 BitComet+0x10ab14 0012fd00 00695eac 00000000 0001059c 00000113 BitComet+0x295e1f 0012fd20 7e418734 0001059c 00000113 00000000 BitComet+0x295eac 0012fd4c 7e418816 00695e78 0001059c 00000113 user32!InternalCallWinProc+0x28 0012fdb4 7e4189cd 0017ace8 00695e78 0001059c user32!UserCallWinProcCheckWow+0x150 0012fe14 7e418a10 001790e8 00000000 00000000 user32!DispatchMessageWorker+0x306 0012fe24 0069b41c 001790e8 001790e8 00975040 user32!DispatchMessageW+0xf 00000000 00000000 00000000 00000000 00000000 BitComet+0x29b41c Note it's waiting on a return from the mswsock call, which is the socket functionality. It sent data over the wire, and is waiting for a response. Now, onto the msn messenger dump, showing similar issues: // Again, two critical sections are locked, but the first in this list is // the important one: 0:000> !locks CritSec +25b29f0 at 025b29f0 LockCount 0 RecursionCount 1 OwningThread eac EntryCount 0 ContentionCount 0 *** Locked CritSec +25b2b18 at 025b2b18 LockCount 0 RecursionCount 1 OwningThread b88 EntryCount 0 ContentionCount 0 *** Locked // Again, this is blocked in thread 0 waiting on mswsock, so the app // is going to appear hung until this network request comes back: 0:000> kb ChildEBP RetAddr Args to Child 0006faf0 7c90d8ef 71a5da55 000007bc 00000000 ntdll!KiFastSystemCallRet 0006faf4 71a5da55 000007bc 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc 0006fb98 71a555af 025b2958 0006fcd8 00000010 mswsock!SockDoConnectReal+0x1b0 0006fc40 71a5542c 00000660 0006fcd8 00000010 mswsock!SockDoConnect+0x392 0006fc70 71ab40bd 00000660 0006fcd8 00000010 mswsock!WSPConnect+0xc6 0006fcbc 004a2084 00000660 0006fcd8 00000010 ws2_32!connect+0x4f WARNING: Stack unwind information not available. Following frames may be wrong. 0006fcec 004a971f d8d094db 004a96b8 01f18cd8 msnmsgr+0xa2084 0006fd10 004aef2b 00170388 01fe57e0 d8d0948f msnmsgr+0xa971f 0006fd44 0047a120 00000400 00296220 008bc214 msnmsgr+0xaef2b 0006fd5c 0046fdc3 00000400 00000003 00000000 msnmsgr+0x7a120 0006fd74 0046fd76 0001081e 00000400 00000003 msnmsgr+0x6fdc3 0006fdc4 7e418734 00296220 00000000 00000003 msnmsgr+0x6fd76 0006fdf0 7e418816 01a40f30 0001081e 00000400 user32!InternalCallWinProc+0x28 0006fe58 7e4189cd 00000000 01a40f30 0001081e user32!UserCallWinProcCheckWow+0x150 0006feb8 7e418a10 0006fed8 00000000 0006fef4 user32!DispatchMessageWorker+0x306 0006fec8 0040328d 0006fed8 00926470 0001081e user32!DispatchMessageW+0xf 0006fef4 00542f57 008bb820 591610fb 0006ff24 msnmsgr+0x328d 0006ff04 0055d188 00000000 0055d0be 009294a8 msnmsgr+0x142f57 0006ff24 00561550 0009233d 0006ffc0 00561581 msnmsgr+0x15d188 0006ff30 00561581 00400000 00000000 0009233d msnmsgr+0x161550 0006ffc0 7c816fd7 00340039 00320032 7ffd7000 msnmsgr+0x161581 0006fff0 00000000 005708ed 00000000 78746341 kernel32!BaseProcessStart+0x23 And looking at the full dump, I'm going to blame either the PCTools software's TDI driver, or the Nvidia miniport driver: // In the full dump, we have an abandoned mutex that appears to be // created by a network driver: 0: kd> dt nt!_KMUTANT 0xba398cc0 +0x000 Header : _DISPATCHER_HEADER +0x010 MutantListEntry : _LIST_ENTRY [ 0x0 - 0x0 ] +0x018 OwnerThread : (null) +0x01c Abandoned : 0 '' // it says it isn't abandoned, but it really is... +0x01d ApcDisable : 0x1 '' // Looking at the nv4_mini driver's callstacks, I can see that this is // a mutex similar to the ones it's currently set up: 0: kd> !thread 89b6fda8 THREAD 89b6fda8 Cid 0004.04f0 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable ba398cc0 Mutant - owning thread 0 ba398cb0 SynchronizationEvent Not impersonating DeviceMap e1009288 Owning Process 89e23830 Image: System Attached Process N/A Image: N/A Wait Start TickCount 1109 Ticks: 2319973 (0:10:04:09.578) Context Switch Count 1 UserTime 00:00:00.000 KernelTime 00:00:00.000 Start Address nv4_mini (0xba020030) Stack Init b781f000 Current b781ed10 Base b781f000 Limit b781c000 Call 0 Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0 ChildEBP RetAddr Args to Child b781ed28 80502d26 00000000 89b6fda8 804fac40 nt!KiSwapContext+0x2f (FPO: [Uses EBP] [0,0,4]) b781ed34 804fac40 00000000 89b6fda8 804fa9bc nt!KiSwapThread+0x8a (FPO: [0,0,0]) (CONV: fastcall) b781ed6c ba020068 00000002 b781eda8 00000000 nt!KeWaitForMultipleObjects+0x284 (FPO: [Non-Fpo]) (CONV: stdcall) WARNING: Stack unwind information not available. Following frames may be wrong. b781edac 805ce84c 00000000 00000000 00000000 nv4_mini+0x1d068 ba398cb0 00000000 89b6fe30 8886f0a8 00080002 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo]) (CONV: stdcall) 0: kd> dt nt!_KMUTANT ba398cc0 +0x000 Header : _DISPATCHER_HEADER +0x010 MutantListEntry : _LIST_ENTRY [ 0x0 - 0x0 ] +0x018 OwnerThread : (null) +0x01c Abandoned : 0 '' +0x01d ApcDisable : 0x1 '' There are 4 mutexes like the one above, all waiting on the abandoned mutex. Since this is a mutex in a network driver, this is the likely culprit causing the mswsock hangs, as the network stack is likely hung at this point. Here's the nvidia and pctools drivers - I'd remove the pctools driver (and the Acronis software too, as that has a LOT of waiters here that you should remove for testing, and only put back when the problem is gone) and update the nvidia driver(s): 0: kd> lmvm nv4_mini start end module name ba003000 ba3c17a0 nv4_mini (deferred) Image path: \SystemRoot\system32\DRIVERS\nv4_mini.sys Image name: nv4_mini.sys Timestamp: Thu Jun 01 21:11:09 2006 (447F902D) CheckSum: 003C1170 ImageSize: 003BE7A0 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 0: kd> lmvm pctfw2 start end module name b7986000 b79c0000 pctfw2 (no symbols) Loaded symbol image file: pctfw2.sys Image path: \??\C:\WINDOWS\system32\drivers\pctfw2.sys Image name: pctfw2.sys Timestamp: Thu Nov 29 15:27:58 2007 (474F20CE) CheckSum: 0003BEFC ImageSize: 0003A000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

I don't know, but it looks like the intelide.sys driver is updated as provided by the vendor. Perhaps they were thinking that a driver written to the API specifications shouldn't crash when the kernel underneath it is updated? It wouldn't be the first time a driver vendor's bugginess was brought about during a kernel update... . Sorry to hear about your problems though - you should definitely make Microsoft aware of the crashes, because if you've got a bug and you don't report it, it's less likely to get fixed.

You should have mentioned that first, it's a known bug.

And it's the weekend and I have a wife and kids . Nitroshift said what I would have though - upload it somewhere that hosts files on the internet, and post the download link here.

Even better - pick a charity and give to it .