If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

ASP.NET 2.0 Crash case study: Unhandled exceptions

ASP.NET 2.0 Crash case study: Unhandled exceptions

Rate This
  • Comments 84

For a long time all my case studies have been on 1.1. it’s time to venture out in 2.0 land and look at what may seem like a 2.0 specific issue.

 

I say “may seem” because this case study will only directly crash if you are using 2.0, but as you’ll learn later the problem existed in 1.1 and 1.0, it was just way harder to track down.

 

Problem description:

 

Once in a while ASP.NET crashes and we see events in the system event log like this one

 

Event Type:       Warning
Event Source:    W3SVC
Event Category: None
Event ID:          1009
Date:               
2006-04-25
Time:               
09:41:22
PM User:           N/A
Computer:        
SUBSPACE1
Description:
A process serving application pool
'ASP.NET V2.0' terminated unexpectedly. The process id was ‘1732’. The process exit code was ‘0xe0434f4d’.

 

Or this one

 

Event Type:       Warning

Event Source:    W3SVC

Event Category: None

Event ID:          1011

Date:                2006-04-25

Time:                09:41:22

User:                N/A

Computer:         SUBSPACE1

Description:

A process serving application pool 'ASP.NET V2.0' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '6256'. The data field contains the error number.

 

And in the application event log we get a pretty cryptic error message like this one

 

Event Type:       Error

Event Source:    .NET Runtime 2.0 Error Reporting

Event Category: None

Event ID:          5000

Date:                2006-04-25

Time:                09:41:20

User:                N/A

Computer:         SUBSPACE1

Description:

EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_code.pn5mfdcr, P5 0.0.0.0, P6 444dcf44, P7 5, P8 5, P9 system.dividebyzeroexception, P10 NIL.

 

 

Initial thoughts:

 

Ok, so what do we know about the issue?  We know that asp.net terminated unexpectedly, and that right before this we got a System.DivideByZeroException…. We also know that the process exit code was 0xe0434f4d whatever that means, hmm…

 

Usually when you get a stopped unexpectedly error message the exit code will be the type of exception that caused the crash.  For example a 0xC0000005 means you got a second chance access violation, 0x800703e9 means you suffered a StackOverflowException but what about 0xe0434f4d? 

 

0xe0434f4d is the exception code for CLR (.net) exceptions, so any managed exception like a NullReferenceException or InvalidOperationException or SQLException… basically all managed exception are natively referred to as 0xe0434f4d.  In this case, if we look closer at the application event log entry we can see that it is in fact a System.DivideByZero exception.

 

Trivia: Just a piece of info of no particular value that you might want to pull out of pocket on your next dateJ 0xe0434f4d or at least 43 4f 4d  are the ASCII values for the letters COM.

 

But hey now… should a .net exception cause the asp.net process to crash???  If you divide by zero in your page and don’t have a try catch block around it, surely you will get one of those “nice” white and yellow error pages saying that an exception occurred on your page, but the process doesn’t just exit. 

 

The answer is yes, you will get one of those pages because the asp.net global error handler will eventually catch your exception, format it for you and print it out on the screen.  But what happens if it is not on an asp.net request, so there is no-one to feedback the exception to? It’s the old paradox: If a tree falls in the forest and nobody is there, does it still make a sound? 

 

In 1.0 and 1.1 it didn’t.  For example if you throw an exception in a piece of code called on a timer, or use QueueUserWorkItem and throw an exception in code executing there, or otherwise throw exceptions in code that is not running inside the context of an asp.net request, the framework will swallow the exception and continue. Or rather it will stop that thread of execution but it won’t die.

 

Doesn’t sound all that bad right?  Really??? 

 

That thread could have been doing anything, and we will never be the wiser that it died.  It could have been holding a lock of some sort, or it could have been in the middle of cleaning up resources, or really a number of different things that will now never happen, but that may immediately or eventually have really bad side effects like hangs or crashes or memory issues, but the exception will be long gone so we cant figure out what it was.

 

The policy for unhandled exceptions was changed in ASP.NET 2.0 to the default for .net which is a process exit.  This can be changed back by adding the following to the aspnet.config in the frameworks directory, but I wouldn’t recommend it without putting in some preventive measures to take care of potential unhandled exceptions on non ASP.NET threads.

 

<configuration>

<runtime>

<legacyUnhandledExceptionPolicy enabled="true" />

</runtime>

</configuration>

 

Troubleshooting the issue:

 

The main task here is to find out where this DivideByZero exception is coming from and why it occurred so there are two ways to figure this out (short of complete code inspection). 

 

Strategy #1 – logging the exception

 

The first way, and this is the way I would probably recommend, is to create an UnhandledExceptionHandler to log the exception along with its stack trace in the event log as shown in this article http://support.microsoft.com/?id=911816

 

You add the handler like this to the web.config:

 

    <system.web>

      <httpModules>

        <add type="WebMonitor.UnhandledExceptionModule, <strong name>" name="UnhandledExceptionModule"/>

      </httpModules>

         

    </system.web>

 

And it hooks an eventhandler up to the UnhandledException event of the current app domain.

 

You don’t actually need to strong name it and add it to the GAC, however if you plan it in multiple applications you should to avoid for the dll being loaded multiple times.

 

Now the next time you get one of these unhandled exceptions, the process will still exit (unless you change the unhandled exception policy), but you have a very good chance of fixing the issue.

 

The event for the exception in this particular sample looks like this…

 

Event Type:       Error

Event Source:    ASP.NET 2.0.50727.0

Event Category: None

Event ID:         0

Date:                2006-04-25

Time:                09:41:20

User:                N/A

Computer:         SUBSPACE1

Description:

 

UnhandledException logged by UnhandledExceptionModule.dll:

 

appId=/LM/w3svc/1/ROOT/CrashMe

 

type=System.DivideByZeroException

 

message=Attempted to divide by zero.

 

stack=

   at MyFinalizerClass.Finalize()

 

.

 

Bingo!!! So the exception occurs in MyFinalizerClass.Finalize() in the CrashMe application.

 

In fact the code for the finalizer for this class looks like this, so it is pretty obvious what caused it, and our work here is done…

 

    ~MyFinalizerClass()

    {

        int i = 0;

        int j = 9;

        i = j / i;

    }

 

Setting up an UnhandledException handler like this is not limited to 2.0. You can absolutely do this in 1.1 as well to determine if you are throwing any unhandled exceptions. The only modification you need to do to the code outlined in the article is to choose a different dll to gather the version from. A prime candidate for this would be mscorlib.dll.

 

 

Strategy #2 – debugging with windbg

 

If you have read any of my previous posts you know I have a special place in my heart for debugging. If you don’t have an unhandledexception eventhandler you can still find out what the exception was by running adplus in crash mode to generate dumps when the process exits.

 

In this particular case  doing this will result in the following files being generated.

 

C:\debuggers\Crash_Mode__Date_04-25-2006__Time_10-11-3030>dir

 Volume in drive C has no label.

 Volume Serial Number is 30D7-F806

 

 Directory of C:\debuggers\Crash_Mode__Date_04-25-2006__Time_10-11-3030

 

2006-04-25  10:12    <DIR>          .

2006-04-25  10:12    <DIR>          ..

2006-04-25  10:11                      4 404 ADPlus_report.txt

2006-04-25  10:11    <DIR>          CDBScripts

2006-04-25  10:11                      9 420 059 PID-3368__W3WP.EXE__1st_chance_IntegerDivide__mini_12D8_2006-04-25_10-11-51-487_0D28.dmp

2006-04-25  10:12                      108 142 158 PID-3368__W3WP.EXE__1st_chance_Process_Shut_Down__full_12D8_2006-04-25_10-12-02-440_0D28.dmp

2006-04-25  10:12                      108 294 606 PID-3368__W3WP.EXE__2nd_chance_NET_CLR__full_12D8_2006-04-25_10-11-54-690_0D28.dmp

2006-04-25  10:12                      35 324 PID-3368__W3WP.EXE__Date_04-25-2006__Time_10-11-3030.log

2006-04-25  10:11                      9 014 Process_List.txt

               6 File(s)    225 905 565 bytes

               3 Dir(s)   4 592 435 200 bytes free

 

 

So at 10-11-51 a 1st chance IntegerDivide exception occurred, followed by a 2nd chance .NET exception (2nd chance meaning that it wasn’t handled), and finally this was followed by a process shutdown.

 

Concentrating on the 2nd chance exception dump and loading up sos.dll from the framework directory

 

0:020> .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll

 

We can run !threads to give us a list of the threads along with info about which thread the exception occurred on (in this case thread 20, the finalizer thread). 

 

0:020> !threads

ThreadCount: 7

UnstartedThread: 0

BackgroundThread: 7

PendingThread: 0

DeadThread: 0

Hosted Runtime: no

                                                        PreEmptive   GC Alloc                          Lock

   ID    OSID    ThreadOBJ       State        GC          Context                  Domain   Count   APT   Exception

   16    1 c20    000b9778      3808220    Enabled  00000000:00000000 000fddc0     1 Ukn (Threadpool Worker)

  20    2 16d8 000e3bd0      b220 Enabled  0242ab08:0242bf94 000caad8     0 MTA (Finalizer) System.DivideByZeroException (02428f60)

  21    3  b2c 000fa588    80a220 Enabled  00000000:00000000 000caad8     0 MTA (Threadpool Completion Port)

  22    4 16c0 000fd690      1220 Enabled  00000000:00000000 000caad8     0 Ukn

  14    6 1570 0014a970   880a220 Enabled  00000000:00000000 000caad8     0 MTA (Threadpool Completion Port)

  23    7 1b44 00145178   180b220 Enabled  00000000:00000000 000caad8     0 MTA (Threadpool Worker)

  24    5  bac 0014a5b0   880b220 Enabled  00000000:00000000 000caad8     0 MTA (Threadpool Completion Port)

 

 

So from this we know that we are looking at an exception happening during finalization.

 

Since this dump was triggered by the exception this will also be the active thread when you load up the dump.

 

If we look at the native and managed callstack it doesn’t really bring us any closer to the solution…

 

 

0:020> kb 2000

ChildEBP RetAddr  Args to Child             

01eaf9fc 79f97065 e0434f4d 00000001 00000001 kernel32!RaiseException+0x53

01eafa5c 7a05b941 02428f60 00000000 00000000 mscorwks!RaiseTheExceptionInternalOnly+0x226

01eafa70 7a05b9b2 02428f60 00000000 01eafb88 mscorwks!RaiseTheException+0x4c

01eafa98 7a05b9ea 00000000 000e3bd0 4914714b mscorwks!RaiseTheException+0xbe

01eafac4 7a05b9f5 02428f60 00000000 7a0e0701 mscorwks!RealCOMPlusThrow+0x37

01eafad0 7a0e0701 02428f60 7740e5f5 7a36a738 mscorwks!RealCOMPlusThrow+0xa

01eafc00 7a0e16e4 00000000 01eafc38 01eafca8 mscorwks!Thread::RaiseCrossContextException+0x63

01eafcb4 79f3a09c 000fddc0 79f3a0a1 01eafeb4 mscorwks!Thread::DoADCallBack+0x25a

01eafcd0 79f3581e 01eafeb4 79f3ab82 000fddc0 mscorwks!Thread::UserResumeThread+0xf3

01eafcd8 79f3ab82 000fddc0 79f3abb0 01eafd08 mscorwks!ManagedThreadBase::FinalizerAppDomain+0x26

01eafd34 79f350ea 000e3bd0 00000000 01eafd5b mscorwks!SVR::CreateGCHeap+0x163

01eafdb0 79f3500e 00000000 00000000 01eafe6c mscorwks!SVR::CreateGCHeap+0x204

01eafdc8 79ecb4a4 01eafeb4 00000000 00000001 mscorwks!SVR::GCHeap::FinalizerThreadWorker+0xe7

01eafdd8 79ecb442 01eafeb4 01eafe60 79f93fe6 mscorwks!Thread::UserResumeThread+0xfb

01eafe6c 79ecb364 01eafeb4 7740e0c9 00000000 mscorwks!Thread::DoADCallBack+0x355

01eafea8 79ed5e8b 01eafeb4 00000000 000fddc0 mscorwks!Thread::DoADCallBack+0x541

01eafed0 79ed5e56 79f34f4a 00000008 79f6fd87 mscorwks!ManagedThreadBase_NoADTransition+0x32

01eafedc 79f6fd87 79f34f4a 7740e175 00000000 mscorwks!ManagedThreadBase::FinalizerBase+0xb

01eaff14 79ecb00b 00000000 00000000 00000000 mscorwks!SVR::GCHeap::FinalizerThreadStart+0xbb

01eaffb8 77e66063 000e4390 00000000 00000000 mscorwks!Thread::intermediateThreadProc+0x49

01eaffec 00000000 79ecafc5 000e4390 00000000 kernel32!BaseThreadStart+0x34

 

 

0:020> !clrstack

OS Thread Id: 0x16d8 (20)

ESP       EIP    

01eafaac 77e55dea [GCFrame: 01eafaac]

01eafb14 77e55dea [GCFrame: 01eafb14]

01eafd14 77e55dea [GCFrame: 01eafd14]

 

But from the !threads output we get the address of the exception (02428f60) and we can take a deeper look…

 

0:020> !do 02428f60

Name: System.DivideByZeroException

MethodTable: 7915e020

EEClass: 791e97f8

Size: 72(0x48) bytes

 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

Fields:

      MT    Field   Offset                 Type VT     Attr    Value Name

790fa3e0  40000b5        4        System.String  0 instance 02429e78 _className

79109208  40000b6        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod

790fa3e0  40000b7        c        System.String  0 instance 0242a18c _exceptionMethodString

790fa3e0  40000b8       10        System.String  0 instance 02429fb4 _message

79113dfc  40000b9       14 ...tions.IDictionary  0 instance 00000000 _data

790fa9e8  40000ba       18     System.Exception  0 instance 00000000 _innerException

790fa3e0  40000bb       1c        System.String  0 instance 00000000 _helpURL

790f9c18  40000bc       20        System.Object  0 instance 00000000 _stackTrace

790fa3e0  40000bd       24        System.String  0 instance 00000000 _stackTraceString

790fa3e0  40000be       28        System.String  0 instance 0242aab0 _remoteStackTraceString

790fed1c  40000bf       34         System.Int32  0 instance        0 _remoteStackIndex

790f9c18  40000c0       2c        System.Object  0 instance 00000000 _dynamicMethods

790fed1c  40000c1       38         System.Int32  0 instance -2147352558 _HResult

790fa3e0  40000c2       30        System.String  0 instance 0242a3c4 _source

790fe160  40000c3       3c        System.IntPtr  0 instance        0 _xptrs

790fed1c  40000c4       40         System.Int32  0 instance        0 _xcode

 

In particular we can dump out the _remoteStackTraceString and find out where exactly the error occurred.

 

0:020> !do 0242aab0

Name: System.String

MethodTable: 790fa3e0

EEClass: 790fa340

Size: 88(0x58) bytes

 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

String:    at MyFinalizerClass.Finalize()

 

Fields:

      MT    Field   Offset                 Type VT     Attr    Value Name

790fed1c  4000096        4         System.Int32  0 instance       36 m_arrayLength

790fed1c  4000097        8         System.Int32  0 instance       35 m_stringLength

790fbefc  4000098        c          System.Char  0 instance       20 m_firstChar

790fa3e0  4000099       10        System.String  0   shared   static Empty

    >> Domain:Value  000caad8:790d6584 000fddc0:790d6584 <<

79124670  400009a       14        System.Char[]  0   shared   static WhitespaceChars

    >> Domain:Value  000caad8:023d03f0 000fddc0:023d4374 <<

 

Voila, there we have it again… our MyFinalizerClass.Finalize()

 

If you want to take away just one thing from this post, it should be to be careful with the code running on non ASP.NET threads, making sure that you have proper try / catch blocks around any code that could cause an exception.

 

Until next time…

 





  • I'm getting the same error too. I'm also getting Thread aborts and a crashing IIS. I think the source is the .Redirect, because my application is logging this it's own log in a database.

    Anyone found a solution for this?
  • A redirect would occurr on an ASP.NET thread and thus it would not crash the process.  

    It is normal for redirect to throw threadabort exceptions as it has to abort the code execution on the current thread, and this is unharmful, since we are aborting ourselfs and thus we can not be in a part of code where we are executing anything that can not be aborted.

    I think you need to look elsewhere for your crashing exception, a crash dump would probably be the best option.
  • Uhm, yes, your right. Saw that a couple of minutes ago. I've installed IIS diagnostics (max crash logging) and now it's waiting for the next crash.
    Thanks for the quick reply!
  • As part of my &quot;not-my-real-job&quot; time, I do a little website hosting - basically to keep my

  • This is more a general question about HttpModules, all the documentation seems to suggest that when you add an HttpModule to your web.config file you only get one single instance of your HttpModule per HttpApplication, is this really true?

    I've been running some load tests generating 1000s of requests and when I've windbg'd the worker process and done a dumpheap -type on my HttpModule class there's loads of 'em. But if we're only supposed to get one instance per HttpApplication, how's this possible?

  • Actually it appears that ASP.NET creates a pool of HttpModules to handle multiple requests and the number created increases with load. I wonder what algorithm is used to determine how many instances of the HttpModule to create?

    So this would mean that the HttpModule code from the kb article will only work for the first instance of that particular HttpModule.

    Well, you learn something everyday day.

  • I am afraid I don't follow you at all...

    What is the problem?  If you get an unhandled exception, this module will handle it whether there is a pool of such handlers or only one.  Are you seeing something different? I would be a bit surprised if you were...

  • What I mean't was that in the kb article the code uses a static bool to determine whether the module has already been initialized and hence to hook up the event handlers or not in the Init() method.

    So when any subsequent instances of the module class are created this bool flag is already set to true. Which means these instances will not have event handlers set up for them.

    Well, thats what it seems like anyway, as a % of my requests don't get processed. The first x number do, then it goes hit & miss. This only happens under heavy load, ie when I've got a pool of these handlers created. Everytime I've had a request that hasn't been processed I've checked with !dumpheap -type and there's always multiple instances of the module class.

    When I comment out the static bool flag all my requests get processed when it's under load.

    Hope that makes sense.

  • Just in case anyone uses active reports, we ran across an issue where our application was terminating unexpectedly and it turned out to be related to a bug in their code.

    http://www.datadynamics.com/forums/3/96793/ShowPost.aspx#96793

  • Hi Tess,

    I cannot use a debugger to troubleshoot the issue in this case. The HttpModule you referred to works for a ASP.NET app. Can you give me some idea on how to do this for a Windows Service (in 2.0) that is doing some async operations for TCP Sockets?

    Thanks,

    Warrier

  • Hi Warrier,

    Unfortunately a windows service is not "hosted" the same way that an asp.net app is so as you mentioned you don't have the same harness of events, modules and handlers, so you would have to create a harness yourself which is not completely trivial (ok, understatement of the year:))  

    Where do you get the exceptions? Would it be possible to have exception handlers just around the code that makes the async operations?

  • Hi Tess,

    I'm new to WinDbg and you blog was very helpful!

    I've got a question...When I run my application, the worker process crashes.. i started debugging using WinDbg..

    when I open crash dumps, following exceptions is shown

    In w3wp__PID__1368__Date__02_22_2007__Time_11_07_03AM__329__Second_Chance_Exception_E0434F4D.dmp the assembly instruction at kernel32!RaiseException+53 in C:\WINDOWS\system32\kernel32.dll from Microsoft Corporation has caused a CLR Exception of type (System.CannotUnloadAppDomainException) on thread 14

    This exception originated from mscorwks!RaiseTheExceptionInternalOnly+226.

    Thread 14 - System ID 1568

    Entry point   mscorwks!ThreadpoolMgr::intermediateThreadProc

    Create time   2/22/2007 10:56:57 AM

    Time spent in user mode   0 Days 0:0:16.625

    Time spent in kernel mode   0 Days 0:0:25.46

    Function     Arg 1     Arg 2     Arg 3   Source

    kernel32!RaiseException+53     e0434f4d     00000001     00000001    

    mscorwks!RaiseTheExceptionInternalOnly+226     1d00e1d0     00000000     00000000    

    mscorwks!RaiseTheException+4c     1d00e1d0     00000000     019dfb68    

    mscorwks!RaiseTheException+be     00000000     000e1f00     b59aaf96    

    mscorwks!RealCOMPlusThrow+37     1d00e1d0     00000000     7a0e0701    

    mscorwks!RealCOMPlusThrow+a     1d00e1d0     b40c20e3     7a36a7d0    

    mscorwks!Thread::RaiseCrossContextException+63     00000000     019dfc18     019dfc88    

    mscorwks!Thread::DoADCallBack+26c     00000007     79f3a0a1     019dfd88    

    mscorwks!Thread::UserResumeThread+e1     019dfd88     019dfd34     79f93fe6    

    mscorwks!Thread::DoADCallBack+355     019dfd88     b40c26eb     00000001    

    mscorwks!Thread::DoADCallBack+541     019dfd88     00000007     00000000    

    mscorwks!Thread::DoADCallBack+575     00000007     7a07bd61     019dfdf8    

    mscorwks!ManagedThreadBase::ThreadPool+13     00000007     7a07bd61     019dfdf8    

    mscorwks!QueueUserWorkItemCallback+9d     00110a90     77e6bb9d     7a38e228    

    mscorwks!ThreadpoolMgr::ExecuteWorkRequest+40     08e67868     b40c2503     00000000    

    mscorwks!ThreadpoolMgr::WorkerThreadStart+1f2     00000000     00000000     00000000    

    mscorwks!ThreadpoolMgr::intermediateThreadProc+49     000c89a0     00000000     00000000    

    kernel32!BaseThreadStart+34     79f710dd     000c89a0     00000000    

    Using this information i am not able to figure out where the error is occured.

    Also I am creating timer on thread in ASP.Net application and the timer is disposed in Application_End event.

    Can you give me some idea where should i start looking inorder to resolve the issue?

    Thanks

    manche

  • You can try to run !threads to see what the last exception was on that thread and run !pe on it,  or run !dso to find the exception on the stack.  It is definitely an unhandled .net exception but it is not possible from the stack you sent to see what the exception was.

  • Thanks for your response...

    0:014> !threads

    PDB symbol for mscorwks.dll not loaded

    ThreadCount: 10

    UnstartedThread: 0

    BackgroundThread: 10

    PendingThread: 0

    DeadThread: 0

    Hosted Runtime: no

                                         PreEmptive   GC Alloc           Lock

          ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception

     14    1  620 000e1f00   1808220 Enabled  00000000:00000000 000dee68     0 STA (Threadpool Worker) System.CannotUnloadAppDomainException (1d00e1d0)

     16    2  630 000ee228      b220 Enabled  00000000:00000000 000dee68     0 MTA (Finalizer)

     17    3  880 00101f60    80a220 Enabled  00000000:00000000 000dee68     0 MTA (Threadpool Completion Port)

     18    4  884 00105340      1220 Enabled  00000000:00000000 000dee68     0 Ukn

     12    5  1ec 05983130   880a220 Enabled  00000000:00000000 000dee68     0 MTA (Threadpool Completion Port)

     20    6  7c4 00176e68   180b220 Enabled  00000000:00000000 000dee68     0 MTA (Threadpool Worker)

     21    7  9c0 059def98   880b220 Enabled  00000000:00000000 000dee68     0 MTA (Threadpool Completion Port)

     25    a  e6c 08cf8f58   180b220 Enabled  00000000:00000000 109aedd0     1 MTA (Threadpool Worker)

     26    b  78c 08d80370   880b220 Enabled  00000000:00000000 000dee68     0 MTA (Threadpool Completion Port)

     28    c  f38 108e8770      7221 Enabled  00000000:00000000 1090fd38     0 STA

    0:014> !dso

    OS Thread Id: 0x620 (14)

    ESP/REG  Object   Name

    019df9f8 1d00e1d0 System.CannotUnloadAppDomainException

    019df9fc 1d00e1d0 System.CannotUnloadAppDomainException

    019dfa44 1d00e1d0 System.CannotUnloadAppDomainException

    019dfa58 1d00e1d0 System.CannotUnloadAppDomainException

    019dfaac 1d00e1d0 System.CannotUnloadAppDomainException

    019dfab8 1d00e1d0 System.CannotUnloadAppDomainException

    019dfb54 1cfe9cb4 System.CannotUnloadAppDomainException

    019dfb58 1d00cc54 System.Byte[]

    019dfb84 1d00e1d0 System.CannotUnloadAppDomainException

    019dfb88 1d00cc54 System.Byte[]

    019dfb98 1d00cc54 System.Byte[]

    019dfc24 022e5f28 System.Threading.ExecutionContext

    0:014> !pe

    Exception object: 1d00e1d0

    Exception type: System.CannotUnloadAppDomainException

    Message: Error while unloading appdomain. (Exception from HRESULT: 0x80131015)

    InnerException: <none>

    StackTrace (generated):

    <none>

    StackTraceString: <none>

    HResult: 80131015

    0:014> !do 1d00e1d0

    Name: System.CannotUnloadAppDomainException

    MethodTable: 7915d434

    EEClass: 791e7ea4

    Size: 72(0x48) bytes

    (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

    Fields:

         MT    Field   Offset                 Type VT     Attr    Value Name

    790fa3e0  40000b5        4        System.String  0 instance 1d00f048 _className

    79109208  40000b6        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod

    790fa3e0  40000b7        c        System.String  0 instance 1d00f7d8 _exceptionMethodString

    790fa3e0  40000b8       10        System.String  0 instance 1d00f194 _message

    79113dfc  40000b9       14 ...tions.IDictionary  0 instance 1d0104fc _data

    790fa9e8  40000ba       18     System.Exception  0 instance 00000000 _innerException

    790fa3e0  40000bb       1c        System.String  0 instance 00000000 _helpURL

    790f9c18  40000bc       20        System.Object  0 instance 00000000 _stackTrace

    790fa3e0  40000bd       24        System.String  0 instance 00000000 _stackTraceString

    790fa3e0  40000be       28        System.String  0 instance 1d011274 _remoteStackTraceString

    790fed1c  40000bf       34         System.Int32  0 instance        0 _remoteStackIndex

    790f9c18  40000c0       2c        System.Object  0 instance 00000000 _dynamicMethods

    790fed1c  40000c1       38         System.Int32  0 instance -2146234347 _HResult

    790fa3e0  40000c2       30        System.String  0 instance 1d00fa2c _source

    790fe160  40000c3       3c        System.IntPtr  0 instance        0 _xptrs

    790fed1c  40000c4       40         System.Int32  0 instance        0 _xcode

    0:014> !do 1d00f048

    Name: System.String

    MethodTable: 790fa3e0

    EEClass: 790fa340

    Size: 92(0x5c) bytes

    (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

    String: System.CannotUnloadAppDomainException

    Fields:

         MT    Field   Offset                 Type VT     Attr    Value Name

    790fed1c  4000096        4         System.Int32  0 instance       38 m_arrayLength

    790fed1c  4000097        8         System.Int32  0 instance       37 m_stringLength

    790fbefc  4000098        c          System.Char  0 instance       53 m_firstChar

    790fa3e0  4000099       10        System.String  0   shared   static Empty

       >> Domain:Value  000dee68:790d6584 109aedd0:790d6584 05a4bf60:790d6584 08da9588:790d6584 08e39ef0:790d6584 108cb728:790d6584 1090fd38:790d6584 <<

    79124670  400009a       14        System.Char[]  0   shared   static WhitespaceChars

       >> Domain:Value  000dee68:022d13b8 109aedd0:02ae15b0 05a4bf60:023d4778 08da9588:024d163c 08e39ef0:025a5a2c 108cb728:0268db34 1090fd38:026ea248 <<

  • Opps I accidently clicked on submit button..

    I have verified the code and all the threads are disposed. Can you find any details with the give information?

    Once again thanks for all your help...

    Thanks

    manche

Page 3 of 6 (84 items) 12345»
Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post