.NET 2.0 service pack 1 run time error! Only service pack 1 has this problem... RRS feed

  • Question

  • Recently the application that we have developed has the following error pops up shortly after the app starts up.


    Faulting application Appname.exe, version, stamp 4802c849, faulting module mscorwks.dll, version 2.0.50727.1433, stamp 471ef729, debug? 0, fault address 0x00003539.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



    This happens on windows XP with .NET 2.0 service pack 1 (version 2.1.21022), I can fix it by uninstalling it then reinstall the original .NET 2.0 without service pack 1.

    But as soon as windows XP picks up an automatic update and update the .NET to service pack 1, this problem reappears again. Again I had to fixed it by roll it back to .NET 2.0.....


    Does any one have the same problem with .NET 2.0 service pack 1? How do you solve this? Thanks!

    Monday, April 21, 2008 5:06 AM

All replies

  • Can someone please help?

    Now it is happening on our clients too, we have to tell them to disable windows automatic update for now. Because it kills our application everytime, and whenever it happens we had to roll them back to .NET 2.0 to fix this problem.

    Is there a way to disable automatic update just for .NET? Instead of disabling the whole automatic update...
    Wednesday, May 21, 2008 12:23 AM
  • Disabling .NET update doesn't seem to me like a good long-term solution for your customers. That way you will not get for example new security fixes from SP1, etc.

    I would recommend to investigate what's going on in your application that it crashes on 2.0 SP1. That way you can drill it down to either a bug in your code (which you can fix) or a bug in .NET Framework (which you can file).


    -Karel Zikmund

    Wednesday, May 21, 2008 3:37 PM
  • Karel Zikmund - MSFT said:

    Disabling .NET update doesn't seem to me like a good long-term solution for your customers. That way you will not get for example new security fixes from SP1, etc.

    I would recommend to investigate what's going on in your application that it crashes on 2.0 SP1. That way you can drill it down to either a bug in your code (which you can fix) or a bug in .NET Framework (which you can file).


    -Karel Zikmund

    Thanks, but it's hard to investigate why it's crashing since it doesn't happen on our computer. I tried to run a debug version of our application on a client's pc which has this problem, and it worked fine.

    Our application is deployed by ClickOnce technology, and I realize that launching our application directly by the exe will be fine, but launching it by the .appref-ms file will cause it to crash randomly.

    I have also tried to use the debugging tool adplus.vbs to generate a crash dump, but stack trace only showed that it crashed at mscorwks.dll. I am still learning how to use this debugging tool to show all symbols (including .NET symbols), so I can see what exactly happened.

    At the moment we can only either roll back .NET 2.0 SP1 or just launch the app by running the exe (which means they won't detect new updates automatically)...

    Wednesday, June 4, 2008 5:21 AM
  • Even though I agree with Karel on trying to find the cause of the crash, for the short term try forcing your app to use fw2.0 with an app.config file. That way your application will still use fw2.0 even though fw2.0sp1 is installed.
    Wednesday, June 4, 2008 6:01 AM
  • WienerSchnitzel said:

    Even though I agree with Karel on trying to find the cause of the crash, for the short term try forcing your app to use fw2.0 with an app.config file. That way your application will still use fw2.0 even though fw2.0sp1 is installed.

    But 2.0sp1 is not a separate framework from 2.0, it actually overwrites 2.0 isn't it?
    you can only force application to run in fw1.0 or fw1.1 since they are separate framework from 2.0.

    i.e. fw2.0 and fw2.0sp1 have the same version number "v2.0.50727" in app.config:
    <requiredRuntime version=”v2.0.50727″/>

    I am still trying to figure out what crashes my app, there's no exception generated, none of these events were fired:
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(AppDomainUnhandledException); (*)
    Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

    Try, Catch doesn't work.....and I tried to use adplus to generate a crash dump and windbg the dump, but there's no exception's found in the dump too.

    I don't understand why it will only crash in SP1 when it's launched by the .appref-ms file.
    As far as I know the difference is that it will be a networkdeployed App when using the .apprf-ms, and it will be a non-networkdeployed App when running the .exe directly from the clickonce application folder. I hope this is not too confusing.

    Thursday, June 5, 2008 3:05 AM
  • I figured that launching the app directly by the .exe will make the app a standard windows application, so it will not be using the clickonce runtime at all.
    So I guess there are some changes in clickonce runtime of .NET2.0SP1 are causing the crash.
    It could be a permission problem (the error is like "Access violation writing location 0xff018113"), however I am sure our application has full trust permission on.
    Is there anything I can do with CAS (Code Access Security) to make sure my application has full trust permission on?
    It's not easy for me to access client's PC, I wish I can make it happen in house....
    Thursday, June 5, 2008 4:00 AM
  • Yup, the security updates and SP1 is not side-by-side, it overwrites the original version.  Painful isn't it.  The only way to get somewhere is to capture a stack trace with WinDbg so you'll have some idea what might be going wrong.  Security or click-once cannot cause AVs.
    Hans Passant.
    Thursday, June 5, 2008 12:15 PM
  • I ran WinDbg and caught the crash (Access violation), but !pe returns "There is no current managed exception on this thread".
    This is the first time I used windbg so I am not very good at it, can someone please help me out?
    This bit "edx=00000000" looks a bit suspicious...but I don't understand why !pe finds no exception...

    The fact the this only happens with clickonce and in SP1 framework meaning that .NET2.0SP1 clickonce runtime doesn't ignore this first chance exception (since rolling back to .NET 2.0 will be fine).
    Where in .NET2.0 this exception will be ignored I guess? Is there a way to tell the framework to ignore exception like this? I am really stuck, next step will be to print out debug info at a rediculous level....but I can't keep working on client's pc, he needs it for his work too.

    At the moment I can tell the client to run the application directly instead of through .appref-ms, which is fine for him, but I really want to find out what this problem is....

    These are the !dumpstack, !Threads, !pe, k results:

    (a64.68c): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000001 ebx=00e9fb80 ecx=048e6f23 edx=00000000 esi=00e9fb74 edi=048e6f13
    eip=79e73539 esp=00e9fb30 ebp=00e9fb58 iopl=0         nv up ei pl nz na po nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll -
    *** WARNING: Unable to verify checksum for C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Data\5f669e819da7010c1dca347a25597c42\System.Data.ni.dll
    *** ERROR: Module load completed but symbols could not be loaded for C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Data\5f669e819da7010c1dca347a25597c42\System.Data.ni.dll
    79e73539 f00fc101        lock xadd dword ptr [ecx],eax ds:0023:048e6f23=65470065

    0:002> kb
    ChildEBP RetAddr  Args to Child             
    WARNING: Stack unwind information not available. Following frames may be wrong.
    00e9fb58 79ffb929 00174a08 ffeb92df 00000001 mscorwks!LogHelp_NoGuiOnAssert+0x43d
    00e9fba8 79f8770b ffeb929b 0016ea68 0016ea68 mscorwks!NGenCreateNGenWorker+0x1dcb6
    00e9fbec 79ef32ee ffeb94c7 0016ea68 00000000 mscorwks!CreateAssemblyEnum+0x82cf
    00e9fdb0 79fb99b9 00e9feb0 00164f80 00e9fdd4 mscorwks!GetCLRFunction+0x1023a
    00e9fdc0 79ef3207 00e9feb0 00000000 00000000 mscorwks!CorExeMain+0x372
    00e9fdd4 79ef31a3 00e9feb0 00e9fe5c 79f91478 mscorwks!GetCLRFunction+0x10153
    00e9fe68 79ef30c3 00e9feb0 ffeb97d3 00000000 mscorwks!GetCLRFunction+0x100ef
    00e9fea4 79fb9643 00e9feb0 00000000 00161b18 mscorwks!GetCLRFunction+0x1000f
    00e9fecc 79fb960d 79fb990e 00000008 00e9ff14 mscorwks!CreateApplicationContext+0x70a
    00e9fedc 79fba09b 79fb990e ffeb9663 00000000 mscorwks!CreateApplicationContext+0x6d4
    00e9ff14 79f95a2e 00000000 88d47738 804fb048 mscorwks!CorExeMain+0xa54
    00e9ffb4 7c80b683 00164f80 00730074 00610020 mscorwks!ClrCreateManagedInstance+0x8aea
    00e9ffec 00000000 79f959e8 00164f80 00000000 KERNEL32!GetModuleFileNameA+0x1b4

    0:002> .loadby sos mscorwks
    0:002> !DumpStack
    PDB symbol for mscorwks.dll not loaded
    OS Thread Id: 0x68c (2)
    Current frame: mscorwks!LogHelp_NoGuiOnAssert+0x43d
    ChildEBP RetAddr  Caller,Callee
    00e9fb2c 79ffb886 mscorwks!NGenCreateNGenWorker+0x1dc13, calling mscorwks!GetCompileInfo+0x30b7e
    00e9fb58 79ffb929 mscorwks!NGenCreateNGenWorker+0x1dcb6, calling mscorwks!CreateAssemblyEnum+0x83a6
    00e9fba8 79f8770b mscorwks!CreateAssemblyEnum+0x82cf, calling mscorwks!CreateAssemblyEnum+0x82d4
    00e9fbec 79ef32ee mscorwks!GetCLRFunction+0x1023a, calling mscorwks!GetCLRFunction+0x22ff4
    00e9fc08 79365d1c (MethodDesc 0x7914c370 +0x38 System.Runtime.InteropServices.SafeHandle.Finalize()), calling (MethodDesc 0x7914c240 +0 System.Runtime.ConstrainedExecution.CriticalFinalizerObject.Finalize())
    00e9fc14 7c919a9c ntdll!LdrpGetProcedureAddress+0x186, calling ntdll!LdrpSnapThunk
    00e9fc38 79fbcca7 mscorwks!CorExeMain+0x3660
    00e9fc40 79e74466 mscorwks!LogHelp_NoGuiOnAssert+0x136a, calling mscorwks+0x1813
    00e9fc44 79fbccd8 mscorwks!CorExeMain+0x3691, calling mscorwks!LogHelp_NoGuiOnAssert+0x1360
    00e9fc58 7c80261a KERNEL32!WaitForSingleObjectEx+0xda, calling ntdll!RtlDeactivateActivationContextUnsafeFast
    00e9fc60 7c8025f0 KERNEL32!WaitForSingleObjectEx+0xb0, calling KERNEL32!ReleaseMutex+0x5a
    00e9fc88 79e744d0 mscorwks!LogHelp_NoGuiOnAssert+0x13d4, calling ntdll!RtlSetLastWin32Error
    00e9fc8c 79e744d7 mscorwks!LogHelp_NoGuiOnAssert+0x13db, calling mscorwks+0x17c0
    00e9fcb8 79e744f5 mscorwks!LogHelp_NoGuiOnAssert+0x13f9, calling ntdll!RtlSetLastWin32Error
    00e9fcc4 79e789dd mscorwks!LogHelp_NoGuiOnAssert+0x58e1, calling mscorwks+0x18bb
    00e9fcf8 79e789dd mscorwks!LogHelp_NoGuiOnAssert+0x58e1, calling mscorwks+0x18bb
    00e9fcfc 79e7898f mscorwks!LogHelp_NoGuiOnAssert+0x5893, calling mscorwks!LogHelp_NoGuiOnAssert+0x589b
    00e9fd08 79e78994 mscorwks!LogHelp_NoGuiOnAssert+0x5898, calling mscorwks+0x17c0
    00e9fd28 7c90ea53 ntdll!ZwYieldExecution+0xc
    00e9fd2c 7c832998 KERNEL32!SwitchToThread+0x6, calling ntdll!NtYieldExecution
    00e9fd30 79ef3a3f mscorwks!GetCLRFunction+0x1098b, calling mscorwks+0x17c0
    00e9fd4c 79e78944 mscorwks!LogHelp_NoGuiOnAssert+0x5848, calling mscorwks!LogHelp_NoGuiOnAssert+0x584c
    00e9fd60 79ef3a3f mscorwks!GetCLRFunction+0x1098b, calling mscorwks+0x17c0
    00e9fd64 79ef3921 mscorwks!GetCLRFunction+0x1086d, calling mscorwks!GetCLRFunction+0x10871
    00e9fd74 79fbc640 mscorwks!CorExeMain+0x2ff9, calling ntdll!RtlSetLastWin32Error
    00e9fd78 79fbc645 mscorwks!CorExeMain+0x2ffe, calling mscorwks+0x17c0
    00e9fd8c 79ef224b mscorwks!GetCLRFunction+0xf197
    00e9fdb0 79fb99b9 mscorwks!CorExeMain+0x372, calling mscorwks!GetCLRFunction+0x101ff
    00e9fdc0 79ef3207 mscorwks!GetCLRFunction+0x10153
    00e9fdd4 79ef31a3 mscorwks!GetCLRFunction+0x100ef, calling mscorwks!GetCLRFunction+0x10128
    00e9fdfc 79e796d9 mscorwks!LogHelp_TerminateOnAssert+0x3c1, calling mscorwks!LogHelp_NoGuiOnAssert+0x3e6
    00e9fe08 79f97950 mscorwks!ClrCreateManagedInstance+0xaa0c, calling mscorwks!LogHelp_TerminateOnAssert+0x375
    00e9fe68 79ef30c3 mscorwks!GetCLRFunction+0x1000f, calling mscorwks!GetCLRFunction+0x10040
    00e9fea4 79fb9643 mscorwks!CreateApplicationContext+0x70a, calling mscorwks!GetCLRFunction+0xffea
    00e9fecc 79fb960d mscorwks!CreateApplicationContext+0x6d4, calling mscorwks!CreateApplicationContext+0x6d8
    00e9fedc 79fba09b mscorwks!CorExeMain+0xa54, calling mscorwks!CreateApplicationContext+0x6c7
    00e9ff14 79f95a2e mscorwks!ClrCreateManagedInstance+0x8aea
    00e9ffa0 79f95a1c mscorwks!ClrCreateManagedInstance+0x8ad8, calling mscorwks!LogHelp_NoGuiOnAssert+0x61c0
    00e9ffb4 7c80b683 KERNEL32!GetModuleFileNameA+0x1b4

    0:002> !threads
    ThreadCount: 7
    UnstartedThread: 0
    BackgroundThread: 4
    PendingThread: 0
    DeadThread: 2
    Hosted Runtime: no
                                          PreEmptive   GC Alloc           Lock
           ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
       0    1  198 00160038      6020 Enabled  016cbabc:016cd820 00161b18     1 STA
       2    2  68c 0016ea68      b220 Disabled 00000000:00000000 00161b18     0 MTA (Finalizer)
      11    3  9a8 00221bf8    80a220 Enabled  00000000:00000000 00161b18     0 MTA (Threadpool Completion Port)
    XXXX    4    0 0022ea68      5820 Enabled  00000000:00000000 00161b18     0 Ukn
      13    5  36c 03eacfe8   180b220 Enabled  00000000:00000000 00161b18     0 MTA (Threadpool Worker)
      14    6  320 03ea9ec0   180b220 Enabled  00000000:00000000 00161b18     0 MTA (Threadpool Worker)
    XXXX    7    0 03eb3e20      9820 Enabled  00000000:00000000 00161b18     0 Ukn

    0:002> !pe
    There is no current managed exception on this thread
    Friday, June 6, 2008 12:37 AM
  • Maybe you have a bufferoverflow og divided by zero exception. This is does not throw a managed exception. But if you try to generate a full dumpfile with e.g DebugDiag and then look at it with Windbg, the first thing it writes when you open the dmp file is something like this



    This dump file has an exception of interest stored in it.
    The stored exception information can be accessed via .ecxr.
    (1238.e70): Integer divide-by-zero - code c0000094 (first/second chance not available)
    eax=00000001 ebx=058fb540 ecx=00000000 edx=00000000 esi=01ae0048 edi=058fb540
    eip=01071b7d esp=0df5e560 ebp=0df5e574 iopl=0         nv up ei pl zr na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
    01071b7d f7f9            idiv    eax,ecx

    And here you can see that windbg tells us that (on line three), that it is a divide-by-zero, and first/second chance exception is not available.


    Thursday, December 1, 2011 10:19 PM