I hope someone can help.I am running Windows 2003 Server SP2and at boot time it take approx. 30 minutes to load. Once loaded I find that there is a thread in the memory chewing up all the CPU (100%) which is ntdll.dll!RtlSetLastWin32ErrorAndNtStatusFromNtStatus. In Process Explorer it shows it under SVCHost.exe. In order to speed up the computer I kill the thread but from then on programs do not load correctly when they attempt to run the same line of code.The computer runs fine in safe mode but any other mode it does the same, if it boots at all. Diagnostic mode fails to load after logon. I have run every virus scan, disabled every service, run all updates, googled everything I can with no progress. I have disabled all the hardward I could to eliminate driver problems.I can't find out what this line of code does, or what I else I can do to try and fix it, please suggest something.

Hi Maca0911, Thank you for posting in windows forums, The issue is much related with 3rd party application as this is not occuring in safe mode but we cannot say until we debug the thread.The best way to diagonize the problem is to perform live debug of the machine for which you need to have the windbg installed on the source machine and then set your target ( problem machine ) and perform remote debugging either using custom ports or using serial cable. Remember to load the corresponding symbol files. After attaching your running process to the windbg you can use !runaway command in the windbg to identify which thread is consuming cpu , as you have used PE to identify it you could check which is the parent process for the corresponding thread or use windbg .Then dump the stack using K command then you have to disassemble the code. I would stop at here because after disassembling i cannot predict the result unless i debug the memory dump / thread dump .The above procedure would be helpful for any one who wish to debug . But generally this requires you to a) identify the thread b) identify the process ( if it is 3rd party app then you might need contact vendor for the debug files ) c) disassemble and identify theproblem TIP : majority of the times this results in a looped function / function which is in loopSo i would recommend you to contact microsoft for the dump analysis where in the engineers are expert enough to provide you the resolution quickly You may obtain the phone numbers for specific technology request please take a look at the web site listed below: https://support.microsoft.com/common/international.aspx?iid=174859&iguid=56907522-6886-4238-a70f-a1d06a4473c7_2_2&rdpath=1sainath !analyze

Thanks for the quick reply.I will try and follow the steps you mentioned. One thing I am trying to find out is what the thread ntdll.dll!RtlSetLastWin32ErrorAndNtStatusFromNtStatus does, it seems to be in most software as I analyse things when they load. Can you tell me?When I find out where the thread is coming from in PE, it originates from DCOM service but I shut that down and it moves to another one, shut that down and it is on the next one. Shut down all the services and windows hangs when I log on.It is hard to imagine that it is a third party service or program when even in Diagnostic Mode it hangs. I can't do much on the computer as programs do not load because, after I shut down the original thread ntdll.dll!RtlSetLastWin32ErrorAndNtStatusFromNtStatus, each program that launches that thread hangs which seems to be most if not all.Any ideas?

Hi Maca0911, RTLsetlastwin32error is a function located in NTDLL.dll file , its an export. Usually dll's can call setlasterror to set the error code. There are two important conditions if you are debugging Setlasterror check for the condition of global variable called g_dwlasterrortobreakon and if the value of the global variable is non zero then setlasterror calls dbgbreakpoint. So if applications are calling setlasterror these calls are redirected to rtlsetlastwin32error.So if you are a classic debugger , put a breakpoint at the setlasterror to check for the value. You have sensed it as a DCOM problem and possible cases would be a heap corruption, i do not see services displayed in SCM , i always see the thread activity as major, so i really do not bother what happens at the win32level or GUI level. All that i want is to see the stack and the parameters of the failing thread. Are you running DCOM applications or applications dependent on DCOM ? and if you have in-house developed applicaiton please use Gflags to run the server code under windbg. And enable first chance exception. You could always capture the relevant logs but your expertise comes when you need to debug them / diagonize them. So do let us know if you need further assistance.For the above you might need to work with microsoft professionals as analyzing crash dump in this forum is not practised.sainath !analyze

Thanks for the reply. I have a small issue, I can't install he debugger as the installer service will not start as it tries to run that same thread and hangs. How can I get a debugger running without installation?

Hi Maca0911, please install the debugger on the different system and enable the boot.ini options to perform live debugging which will not require you to install debugger on problem system sainath !analyze

Thanks for the tip. Sorry if I sound inexperienced. I am attempting to get the debugger online, I have limited resources. Can you tell me what the thread actually does, I know it is a error level reporting thread but what is the code reporting to? Is it to a service or something. Sorry to be a pain.

Hi Maca0911, Not a problem !. To be honest you need to have debugging skills to analyze the threads and disassemble them. If you do not have the experience it would be night mare for you to understand the process. For this reason i suggested you to open a ticket with MS .I thought of a different action plan , you can download the symbol files from the below linkhttp://support.microsoft.com/kb/311503After loading the symbol files you can add the symbol file path in PE and then reproduce the problem , the reason is that if you have a corresponding export you could debug the thread with the exported function and you will understand what exactly is happening. In this process you do not need windbgAnd to remind you need to debug entire stack and not only one thread. You need to see who is calling what and what parameters are passing by which fuction along wiht the memory.sainath !analyze

Hi there, Just want to follow up on the issue to knwo if you are stuck in any of the step i have mentioned above ?sainath !analyze