Troubleshooting Configuration Manager 2012/2007 and SMS 2003 unhandled exceptions

toolsignThis article is designed to cover troubleshooting Configuration Manager unhandled exception  logs (i.e. crash log files) and discusses tips for troubleshooting crashes that occur in the different Configuration Manager components.

What is an unhandled exception?

In almost every Configuration Manger crash there is an exception involved. An exception occurs when an instruction is attempted but fails for some reason (e.g. an Access Violation), so when an exception occurs we need information about that exception or what was in memory when the exception occurred.

Most applications have their own exception handling code and Configuration Manager is no different. Configuration Manager has its own exception handler that is designed to collect certain predefined data such as thread stack information and other data when the exception has occurred. Note that it is also sometimes necessary to do live debugging or post mortem debugging when an application/OS crashes using the Windows debugging tools.

Components that could cause unhandled exception

SMS Executive: SMSEXEC.EXE is the main service that calls many threads. Any running thread will terminate SMS_EXECUTIVE service if an exception occurs in the thread, and the Configuration Manager site server exception handler will collect the required data.

Data collected when Configuration Manger site server encounters an exception

- A log file (CRASH.LOG) that details the thread stacks and very basic information.

- All current .LOG files from the \LOGS folder. These are saved in the \LOGS\CRASHDUMPS\YYYYMMDD_000XX folder where YYYYMMDD is the date when the crash occurred and XX represents the number of crashes in that day.

- An individual thread log for every component at the time of the failure. These files have no extension but can be viewed in any text editor or SMS Trace or CM Trace.

Depending on the nature of crash and current memory conditions, not all of the above information will be captured. Here’s an example:



With this in mind, here are some steps you can do if you experience one of these crashes:

1. Check the LOGS\CRASHDUMPS\CRASH.LOG file and make a note of the failing component and thread ID.



2. Locate the <component>_thread_<thread number> in \Logs and open in a text editor such as Notepad.

3. Look at the bottom of the log to identify the last thing the component was doing when the crash occurred.

4. Take corrective action based on what was occurring. Often there will be a reference in the log to a specific file or object that is causing the crash.

NOTE If nothing useful is found in the log file, a memory dump could be used to analyze the issue deeper.

In our example, examining the CRASH.LOG shows the following:

Time = 08/29/2012 17:28:47.406
Service name = SMS_EXECUTIVE
Executable = D: \Microsoft Configuration Manager\bin\i386\smsexec.exe
Process ID = 11789 (0x2E0D)
Thread ID = 13565 (0x33FD)
Instruction address = 77bd8efa
Description = "The thread tried to read from the virtual address 00000000 for which it does not have the appropriate access."
Raised inside CService mutex = No

Examining the corresponding <component>_thread_<thread number> we can see the following:

Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT
INFO: Processing search path: 'LDAP://OU=xxx ,OU=xx,DC=GLOBAL,DC=xx,DC=xx'. SMS_AD_SYSTEM_DISCOVERY_AGENT
INFO: Full synchronization requested SMS_AD_SYSTEM_DISCOVERY_AGENT

So by looking at this it becomes apparent that the Active Directory System Discovery method is causing the exception to occur. From this point you could continue troubleshooting the cause of the issue with Active Directory System Discovery, or perhaps if this is a secondary site you could disable the Active Directory System Discovery if you do not need it.

Hopefully you’ll never encounter one of the exceptions but at least now you might be able to get a head start on determining the cause of your crash.

Radu Tomoiaga | Support Engineer | Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up:
System Center – Configuration Manager Support Team blog:
System Center – Data Protection Manager Team blog:
System Center – Orchestrator Support Team blog:
System Center – Operations Manager Team blog:
System Center – Service Manager Team blog:
System Center – Virtual Machine Manager Team blog:

Windows Intune:
WSUS Support Team blog:
The AD RMS blog:

App-V Team blog:
MED-V Team blog:
Server App-V Team blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

Comments (3)
  1. José Barba says:

    Good post and nice pictures i like when post come with examples

  2. dominique says:

    Nice post…
    As the SCCM 2007 Environment is running for over 10 years now reaching R3 its end with SCCM 2016 in the process of getting up, why am I getting now issue like this:
    Time = 02/03/2017 22:57:47.720
    Service name = SMS_EXECUTIVE
    Executable = C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsexec.exe
    Process ID = 4992 (0x1380)
    Thread ID = 3272 (0xcc8)
    Instruction address = 31708b04
    Exception = c0000005 (EXCEPTION_ACCESS_VIOLATION)
    Description = “The thread tried to read from the virtual address 7672656F for which it does not have the appropriate access.”
    Raised inside CService mutex = No
    CService mutex description = “”

    if it is working over and over why suddenly it lost access!!!

    1. Hello Dominique

      Check the dbmon.log for related errors or more specific errors. If you help narrowing this down, post your question and the pertinent log entries in the Configuration Manager 2007 forum here:


Comments are closed.

Skip to main content