Quantcast
Channel: AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent
Viewing all 18 articles
Browse latest View live
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 24, 2013, 3:15 pm
$
0
0

New information. Pursuing the clr.dll crash error has led me on an interesting path. It looks like there is a bug in .NET 4.0 clr.dll that can cause this and applying KB2640103 has helped, but not 100%. Now my syncs only occasionally experience this issue.


I surveyed my other working servers and none have .net  4.0 installed.

Today it crashed when manually running delta sync on that MA and along with the original event log, a new .NET Runtime eventlog was created (no doubt due to additional logging provided by the update). Event ID was 1023

Application: miiserver.exe - Framework Version: v4.0.30319 - Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEED00F670 (000007FEECD90000) with exit code 80131506.

Further research pointed to a connect.microsoft.com bug http://connect.microsoft.com/VisualStudio/feedback/details/696561/internal-error-in-the-net-runtime-exit-code-80131506

Microsoft stated: The issue you are seeing here is caused by managed heap corruption. This can be due to a wide variety of issues, such as an incorrect PInvoke signature, native code in your program corrupting the managed heap, or in rare cases a bug in CLR itself. For some background information, there are several places on the internet with information about debugging this type of issue:http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx

This led me to http://support.microsoft.com/kb/2679415 which states:This bug can be encountered when the Garbage Collector is freeing and compacting memory. The error can happen when the Concurrent Garbage Collection is enabled and a certain combination of foreground Garbage Collection and background Garbage Collection occurs. When this situation happens you will see the same call stack over and over. On the heap you will see one free object and before it ends you will see another free object corrupting the heap.

I have therefore followed the instructions at http://msdn.microsoft.com/en-us/library/at1stbec.aspx adding <gcConcurrent enabled="false"/> to the miiserver.exe.config file under the configuration\runtime node. I restarted the service and we'll see if that finally resolves this issue.

↧
Search

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 23, 2013, 2:47 pm
$
0
0
That's my next stop buddy. Just hoping it was something someone had heard of :(
↧
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 11:56 am
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 8:59 am
$
0
0

I just upgraded a server to 4.0.3644.2 from 4.0.3573.2. We have set up a scheduled task that runs a series of run profiles. Now one of my two AD management agents will run fine for two cycles and then subsequent cycles see a stopped-server on delta sync. Looking at the event log, I see that miiserver.exe is crashing on a 0xc0000005 (access denied) exception on either ntdll.dll or clr.dll.

If the service auto recovers, it doesn't fix the issue, however, if I manually restart the fim service, the next 2 cycles again are good, followed by an indefinite number of stopped-server/crash runs. This environment is set up with the same rules extensions and supplementary custom components as 3 other environments that I've upgraded, but this particular environment and this particular MA is the only one that I'm seeing this behavior on. I've run full imports and full syncs on the MA, with no improvement. I moved to 4.0.3684.2 with again no improvement.

For right now, I've put a restart-service command in the ps1 that runs the full sync, however, this is a stop-gap only and cannot be a long term solution. I cannot upgrade to R2 at this time, but will be doing so in about 6 months, so that is not an option at this time.

↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 24, 2013, 3:15 pm
$
0
0

New information. Pursuing the clr.dll crash error has led me on an interesting path. It looks like there is a bug in .NET 4.0 clr.dll that can cause this and applying KB2640103 has helped, but not 100%. Now my syncs only occasionally experience this issue.


I surveyed my other working servers and none have .net  4.0 installed.

Today it crashed when manually running delta sync on that MA and along with the original event log, a new .NET Runtime eventlog was created (no doubt due to additional logging provided by the update). Event ID was 1023

Application: miiserver.exe - Framework Version: v4.0.30319 - Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEED00F670 (000007FEECD90000) with exit code 80131506.

Further research pointed to a connect.microsoft.com bug http://connect.microsoft.com/VisualStudio/feedback/details/696561/internal-error-in-the-net-runtime-exit-code-80131506

Microsoft stated: The issue you are seeing here is caused by managed heap corruption. This can be due to a wide variety of issues, such as an incorrect PInvoke signature, native code in your program corrupting the managed heap, or in rare cases a bug in CLR itself. For some background information, there are several places on the internet with information about debugging this type of issue:http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx

This led me to http://support.microsoft.com/kb/2679415 which states:This bug can be encountered when the Garbage Collector is freeing and compacting memory. The error can happen when the Concurrent Garbage Collection is enabled and a certain combination of foreground Garbage Collection and background Garbage Collection occurs. When this situation happens you will see the same call stack over and over. On the heap you will see one free object and before it ends you will see another free object corrupting the heap.

I have therefore followed the instructions at http://msdn.microsoft.com/en-us/library/at1stbec.aspx adding <gcConcurrent enabled="false"/> to the miiserver.exe.config file under the configuration\runtime node. I restarted the service and we'll see if that finally resolves this issue.

↧
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 23, 2013, 2:47 pm
$
0
0
That's my next stop buddy. Just hoping it was something someone had heard of :(
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 11:56 am
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 8:59 am
$
0
0

I just upgraded a server to 4.0.3644.2 from 4.0.3573.2. We have set up a scheduled task that runs a series of run profiles. Now one of my two AD management agents will run fine for two cycles and then subsequent cycles see a stopped-server on delta sync. Looking at the event log, I see that miiserver.exe is crashing on a 0xc0000005 (access denied) exception on either ntdll.dll or clr.dll.

If the service auto recovers, it doesn't fix the issue, however, if I manually restart the fim service, the next 2 cycles again are good, followed by an indefinite number of stopped-server/crash runs. This environment is set up with the same rules extensions and supplementary custom components as 3 other environments that I've upgraded, but this particular environment and this particular MA is the only one that I'm seeing this behavior on. I've run full imports and full syncs on the MA, with no improvement. I moved to 4.0.3684.2 with again no improvement.

For right now, I've put a restart-service command in the ps1 that runs the full sync, however, this is a stop-gap only and cannot be a long term solution. I cannot upgrade to R2 at this time, but will be doing so in about 6 months, so that is not an option at this time.

↧
Search

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 24, 2013, 3:15 pm
$
0
0

New information. Pursuing the clr.dll crash error has led me on an interesting path. It looks like there is a bug in .NET 4.0 clr.dll that can cause this and applying KB2640103 has helped, but not 100%. Now my syncs only occasionally experience this issue.


I surveyed my other working servers and none have .net  4.0 installed.

Today it crashed when manually running delta sync on that MA and along with the original event log, a new .NET Runtime eventlog was created (no doubt due to additional logging provided by the update). Event ID was 1023

Application: miiserver.exe - Framework Version: v4.0.30319 - Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEED00F670 (000007FEECD90000) with exit code 80131506.

Further research pointed to a connect.microsoft.com bug http://connect.microsoft.com/VisualStudio/feedback/details/696561/internal-error-in-the-net-runtime-exit-code-80131506

Microsoft stated: The issue you are seeing here is caused by managed heap corruption. This can be due to a wide variety of issues, such as an incorrect PInvoke signature, native code in your program corrupting the managed heap, or in rare cases a bug in CLR itself. For some background information, there are several places on the internet with information about debugging this type of issue:http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx

This led me to http://support.microsoft.com/kb/2679415 which states:This bug can be encountered when the Garbage Collector is freeing and compacting memory. The error can happen when the Concurrent Garbage Collection is enabled and a certain combination of foreground Garbage Collection and background Garbage Collection occurs. When this situation happens you will see the same call stack over and over. On the heap you will see one free object and before it ends you will see another free object corrupting the heap.

I have therefore followed the instructions at http://msdn.microsoft.com/en-us/library/at1stbec.aspx adding <gcConcurrent enabled="false"/> to the miiserver.exe.config file under the configuration\runtime node. I restarted the service and we'll see if that finally resolves this issue.

↧
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 23, 2013, 2:47 pm
$
0
0
That's my next stop buddy. Just hoping it was something someone had heard of :(
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 11:56 am
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 8:59 am
$
0
0

I just upgraded a server to 4.0.3644.2 from 4.0.3573.2. We have set up a scheduled task that runs a series of run profiles. Now one of my two AD management agents will run fine for two cycles and then subsequent cycles see a stopped-server on delta sync. Looking at the event log, I see that miiserver.exe is crashing on a 0xc0000005 (access denied) exception on either ntdll.dll or clr.dll.

If the service auto recovers, it doesn't fix the issue, however, if I manually restart the fim service, the next 2 cycles again are good, followed by an indefinite number of stopped-server/crash runs. This environment is set up with the same rules extensions and supplementary custom components as 3 other environments that I've upgraded, but this particular environment and this particular MA is the only one that I'm seeing this behavior on. I've run full imports and full syncs on the MA, with no improvement. I moved to 4.0.3684.2 with again no improvement.

For right now, I've put a restart-service command in the ps1 that runs the full sync, however, this is a stop-gap only and cannot be a long term solution. I cannot upgrade to R2 at this time, but will be doing so in about 6 months, so that is not an option at this time.

↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

December 19, 2013, 7:25 am
$
0
0

Hello,

Have you find the solution to the stopped-server issue (clr.dll, ntdll.dll , .NET 4)?

I have exactly the same problem on FIM Sync 2010 R2 sp1, it seems better with gcConcurrent to false,

but when I stop running synchros during 10 minutes and re-run a full sync, FIM throws the exception at the first execution profile.

Thanks for your help

↧
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

December 19, 2013, 7:25 am
$
0
0

Hello,

Have you find the solution to the stopped-server issue (clr.dll, ntdll.dll , .NET 4)?

I have exactly the same problem on FIM Sync 2010 R2 sp1, it seems better with gcConcurrent to false,

but when I stop running synchros during 10 minutes and re-run a full sync, FIM throws the exception at the first execution profile.

Thanks for your help

↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 24, 2013, 3:15 pm
$
0
0

New information. Pursuing the clr.dll crash error has led me on an interesting path. It looks like there is a bug in .NET 4.0 clr.dll that can cause this and applying KB2640103 has helped, but not 100%. Now my syncs only occasionally experience this issue.


I surveyed my other working servers and none have .net  4.0 installed.

Today it crashed when manually running delta sync on that MA and along with the original event log, a new .NET Runtime eventlog was created (no doubt due to additional logging provided by the update). Event ID was 1023

Application: miiserver.exe - Framework Version: v4.0.30319 - Description: The process was terminated due to an internal error in the .NET Runtime at IP 000007FEED00F670 (000007FEECD90000) with exit code 80131506.

Further research pointed to a connect.microsoft.com bug http://connect.microsoft.com/VisualStudio/feedback/details/696561/internal-error-in-the-net-runtime-exit-code-80131506

Microsoft stated: The issue you are seeing here is caused by managed heap corruption. This can be due to a wide variety of issues, such as an incorrect PInvoke signature, native code in your program corrupting the managed heap, or in rare cases a bug in CLR itself. For some background information, there are several places on the internet with information about debugging this type of issue:http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx

This led me to http://support.microsoft.com/kb/2679415 which states:This bug can be encountered when the Garbage Collector is freeing and compacting memory. The error can happen when the Concurrent Garbage Collection is enabled and a certain combination of foreground Garbage Collection and background Garbage Collection occurs. When this situation happens you will see the same call stack over and over. On the heap you will see one free object and before it ends you will see another free object corrupting the heap.

I have therefore followed the instructions at http://msdn.microsoft.com/en-us/library/at1stbec.aspx adding <gcConcurrent enabled="false"/> to the miiserver.exe.config file under the configuration\runtime node. I restarted the service and we'll see if that finally resolves this issue.

↧
Search

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 23, 2013, 2:47 pm
$
0
0
That's my next stop buddy. Just hoping it was something someone had heard of :(
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 11:56 am
↧
↧

AD MA Delta Sync runs twice then FIM Sync Service crashes on subsequent

May 20, 2013, 8:59 am
$
0
0

I just upgraded a server to 4.0.3644.2 from 4.0.3573.2. We have set up a scheduled task that runs a series of run profiles. Now one of my two AD management agents will run fine for two cycles and then subsequent cycles see a stopped-server on delta sync. Looking at the event log, I see that miiserver.exe is crashing on a 0xc0000005 (access denied) exception on either ntdll.dll or clr.dll.

If the service auto recovers, it doesn't fix the issue, however, if I manually restart the fim service, the next 2 cycles again are good, followed by an indefinite number of stopped-server/crash runs. This environment is set up with the same rules extensions and supplementary custom components as 3 other environments that I've upgraded, but this particular environment and this particular MA is the only one that I'm seeing this behavior on. I've run full imports and full syncs on the MA, with no improvement. I moved to 4.0.3684.2 with again no improvement.

For right now, I've put a restart-service command in the ps1 that runs the full sync, however, this is a stop-gap only and cannot be a long term solution. I cannot upgrade to R2 at this time, but will be doing so in about 6 months, so that is not an option at this time.

↧
Viewing all 18 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>