none
Miiserver.exe APPCRASH on ECMA2 during Delta Import RRS feed

  • Question

  • All,

    I all of a sudden seem to be getting a recurring app crash when running a ECMA2 (incidentally, during Delta Import operation).  It was working fine last week, and the only thing that may be different is the number of records being returned to the ECMA2 (5 - 10 last week, 350 today when I run it).  Here is the error:

    Faulting application name: miiserver.exe, version: 4.1.3114.0, time stamp: 0x50ad5a13

    Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e

    Exception code: 0x80000003

    Fault offset: 0x00000000000c40bf

    Faulting process id: 0x570

    Faulting application start time: 0x01ce5bba32023801

    Faulting application path: E:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe

    Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

    Report Id: 00c7a8dd-c7ae-11e2-a3d2-005056830023

    I also have this:

    Fault bucket , type 0

    Event Name: APPCRASH

    Response: Not available

    Cab Id: 0

    Problem signature:

    P1: miiserver.exe

    P2: 4.1.3114.0

    P3: 50ad5a13

    P4: ntdll.dll

    P5: 6.1.7601.17725

    P6: 4ec4aa8e

    P7: 80000003

    P8: 00000000000c40bf

    P9:

    P10:

    Attached files:

    C:\Users\_FIMSyncServiceDev\AppData\Local\Temp\WER149D.tmp.appcompat.txt

    C:\Users\_FIMSyncServiceDev\AppData\Local\Temp\WER154A.tmp.WERInternalMetadata.xml

    C:\Users\_FIMSyncServiceDev\AppData\Local\Temp\WER156A.tmp.hdmp

    C:\Users\_FIMSyncServiceDev\AppData\Local\Temp\WER3632.tmp.mdmp

    These files may be available here:

    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_miiserver.exe_b72b2ea9975da78208fb936402f66ef4f61953d_cab_0ca13861

    Analysis symbol:

    Rechecking for solution: 0

    Report Id: 00c7a8dd-c7ae-11e2-a3d2-005056830023

    Any ideas on what could be causing this all of a sudden?  I don't believe anything changed with my environment since it was last successfully working, again only the number of records being processed in the delta import.

    Tuesday, May 28, 2013 4:02 PM

All replies

  • What is your import page size?  Surprisingly, FIM throws an error when the number of records imported exceeds the run step's page size.  (I would have expected the page size to be more of a suggestion than a requirement.)

    Steve Kradel, Zetetic LLC

    Tuesday, May 28, 2013 6:10 PM
  • Default Import Page Size on this ECMA2 is 1000

    Max Import Page Size on this ECMA2 is 5000

    So given we are only talking approx. 350 records which I am attempting to import (compared to 5 - 10 I was processing last week)...this should not be a factor, correct?

    Tuesday, May 28, 2013 7:07 PM
  • Probably not the issue then, unless you have set a smaller page size on the individual run step.

    I imagine we'd have to see your ECMA2 code to speculate further.


    Steve Kradel, Zetetic LLC

    Tuesday, May 28, 2013 7:14 PM
  • I tried debugging by attaching to process, but since the app crashes, the managed .NET code associated with the ECMA2 extension actually never throws an exception of any sort.  Therefore, I don't think sharing the code would be useful right now.  As I mentioned, this was working with no problem last week.

    I was curious if anyone else had experienced those type of errors I provided above (i.e. "Faulting application name: miiserver.exe...Faulting module name: ntdll.dll") when using an ECMA2.

    If so, please advise.  Thanks!

    Tuesday, May 28, 2013 8:05 PM
  • If you're absolutely certain that the .NET code never runs, then it is pretty nearly impossible for the number of records to influence the result... I would suspect that the extension code has run, and the FIM internals had some kind of problem with the results or state of the environment.

    FWIW, I never, ever debug by attaching--only via logging with a good logging package--and it's served me well for developing some rather complex ECMAs.


    Steve Kradel, Zetetic LLC

    Tuesday, May 28, 2013 8:10 PM
  • It might be some system update installed, or other environment change.

    Try installing latest FIM fixpack, your version is not the latest one.

    Tuesday, May 28, 2013 8:20 PM
  • Maybe the CS is corrupted somehow, is it possible to delete the connector space and run a full import and afterwards running delta's again, just make sure everything is correctly joined back after you delete the connector space before doing something else (otherwise you get provisioning errors, but it really depends on your implementation) 

    Need realtime FIM synchronization and advanced reporting? check out the new http://www.imsequencer.com that supports FIM 2010, Omada Identity Manager, SQL, File, AD or Powershell real time synchronization!

    Wednesday, May 29, 2013 6:00 AM
  • Thanks, all...I will give these suggestions a try and report back.
    Thursday, May 30, 2013 5:37 PM