hi, one of our dc got blue screen today. I got this error event Event Type: Error Event Source: System Error Event Category: (102) Event ID: 1003 Date: 2/24/2010 Time: 3:26:17 PM User: N/A Computer: dc1 Description: Error code 1000007e, parameter1 c0000005, parameter2 00000000, parameter3 b466c17c, parameter4 b466be78. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 53 79 73 74 65 6d 20 45 System E 0008: 72 72 6f 72 20 20 45 72 rror Er 0010: 72 6f 72 20 63 6f 64 65 ror code 0018: 20 31 30 30 30 30 30 37 1000007 0020: 65 20 20 50 61 72 61 6d e Param 0028: 65 74 65 72 73 20 63 30 eters c0 0030: 30 30 30 30 30 35 2c 20 000005, 0038: 30 30 30 30 30 30 30 30 00000000 0040: 2c 20 62 34 36 36 63 31 , b466c1 0048: 37 63 2c 20 62 34 36 36 7c, b466 0050: 62 65 37 38 be78 can anybody give me a hint? Thanks in advance!

Hi , For analyzing the root cause of the problem and fix in case if the issue belongs to microsoft component we would require you to collect the memory dump and analyze it .You can configure server to collect the memory dump in the event of server crash ( not application crash ) and you can analyze the dump if you have expertise in analyzing iwth out the source files and honest opinion is to have assembly knowledge.You have another option by opening a ticket with microsoft which will be faster means of resolving the issue. 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=1 Hope the issue will be resolved soon.

Use the debugging tools like WinDbg or DEBUG ( built-in inside windows ) to analyze the dump files.Usually, this would be related to some applications that malfunctioned or that has been corrupted . What was the last application that you installed ? Looking at the Event ID rawly, it looks like its related to the AD or some network issue.Did you check on the Event Vwr on the previous activities?- Still a Learner :) -

Hi Xerebroom,Windb is not built inside windows, you have to download it from the windows webiste. And you need to very specific when you say "related to some applications" because majority of the BSOD are caused due to sys files and all the sys files load at the kernel space and not the user mode space.Your OS is divided into user mode and kernel mode biforcated by subsystem dll . Application corruption would never cause BSOD. You cannot predict by event ID , you need analyze the memory dump which is only way to find the root cause of hte problem. AD / networking is very broad , eg: AD is user mode component with some components loading at the kernel space . Networking is all about protocols out of which few drivers are loaded in kernel space such as mrxsmb.sys , srv.sys etc.. You NDIS stack is kernel mode and not user mode.

Hi Sainath,No, I didnt mean WinDB is built-in inside windows, thats the reason y I separated Windb and DEBUG.DEBUG is built-in inside windows,thats wat I meant :) Some of the applications that I have encountered with in my working places has been found to be the main culprit of servers being crashed when they are being executed remotely or thru GPU.So,when the system reboots , what happens is that the changes takes effect,thus it crashes again. Am i being right here Sainath? Correct me if I'm wrong here sir.This is duely caused by inefficiency of testing as well as lack of testing scopes for it.True ? N yes, I agree with what you said earlier, n that was what I was suggesting as well.Right ? I asked him to use the debugging tools to find the cause of the BSOD.Was I saying that he shudnt do it ? :D hehehheehe..The reason why I said it could be a networking issue is because sometimes, when the address negotiation is being done, it could not resolve properly, thus it would crash instantly. Correct Sainath ? But theres this 1 question thats been bugging me about this actually,how could this handshake negotiation fail when its working properly all the other times ? Im still unclear about this, can u explain to me Sai? The other reason, which is actually the most common reason for BSOD is because of the drivers itself right Sai ? Thanks 4 your time :) Enjoyed reading the responses earlier ( Thumbs up :) )- Still a Learner :) -

Hi Sainath,Some of the applications that I have encountered with in my working places has been found to be the main culprit of servers being crashed when they are being executed remotely or thru GPU.So,when the system reboots , what happens is that the changes takes effect,thus it crashes again. Am i being right here Sainath? Correct me if I'm wrong here sir.This is duely caused by inefficiency of testing as well as lack of testing scopes for it.True ? Thanks 4 your time :) Enjoyed reading the responses earlier ( Thumbs up :) ) - Still a Learner :) - When you said applicaitons , there are different way that one should see it . Your application might be coded as a) UI b) as service End of the day everything is nothing but a exe --> process --> thread and your code has a) code segmentb) data segment which fits into the memory for execution after appropriate compilation is done. Many of the Software test engineers , Junior developers doesnt look at the low level implementation of the code or the program implemenation , many of us wants the code to be executed and output is presented, which become tough when you debug any application. Some of the main aspects which one should consider while troubleshooting or debugging application is to understand a) is this network application ? or non-network applicaiton, by saying this i am more towards client server model, many of the code you write today falls under client server model , but there are many other applicatinos which are non client server specific. But every application has its own process , thread and handle references. b) Language you have used , many of the software test engineers are equipped with testingn tools which compare and give them result , many developers either have tough time troubleshooting their own written code , the reason because of wrapping earlier win32 was used to code programs , for simple window / frame i have to use 250 + lines of code , but today its simplified , you use MFC. c) segregating between user mode and kernel mode. This is one of the tough one which every one misses, i have seen users are very strong at visual studio debugging , but not at the systems level. When you are implementing your code , you need to understand that there are 2 main components , you app works at user level and rest all system implementation works at kernel level ( broader sense ) , you need to note down your applicaiton code flow which saves you lot of time . To debug application you need to concentrate on both user mode and kernle mode, system crash is the last attempt that OS makes to save itself from becoming compromised. OS is intelligent enough to calculate that some of the application code is trying to manipulate subsytem data and it throws out an BSOD . So you need to be very careful when commenting i have a system crash , which for an debugger thinks in differnet ways as explained above. And when you said your applications crashed , there is a lot to debug a) which application is crashingb) dwell down to particual processc) which thread in a process is causing the issue , because thread is the executable component in process d) now its get more tough , you need to anlayze the call stack e) after whch the parameters passed on to certain function f) finally i disassmble the code to check the assembly So for troubleshooting the hang or crash you need to have assembly language knowledge which i wrote in my previous email.======================================================================================The reason why I said it could be a networking issue is because sometimes, when the address negotiation is being done, it could not resolve properly, thus it would crash instantly. Correct Sainath ?Why would my system crash if address negotiation is failing . Please understand that Network comprises of tons of protocols out of which the major one is TCP , IP , UDP , you need to have strong analysis of these protocols along with the NDIS stack. I understand you have read through the OSI stack serveral times, so when you say address negotiation are u referring to ARP ? or TCP session initialization. It is very hard to say what causes the crash without analyzing the dump. So if any one gives instant answer with respect to system crashes , they have to be strong at debugging.