Control change causes IDE to crash.

This is related to my previous post on how a rebuild causes the IDE to crash. I have more info, including some debbuger output from the memory dump that is created when the IDE crashes.

First the circumstances that cause the crash.

I wrote a WinForms Control. It can be dragged into the designer and used like any other control. When it is used in projects that are not written using the designer, they build and execute just fine. The problem comes when it is open in the designer. It causes a crash any time anything changes the underlying code enough to cause the designer to refactor things. If I try to build a project that has the control in it, the IDE crashes. If I build the .dll containing the control and the control is open in another designer, the IDE crashes. If I try to close the designer window for the form that contains the control, the IDE crashes. In general, I can not do anything with the designer at all using my control without it eventually killing the IDE.

The things I have tried to fix the problem.

First thing I thought it was, was improper serialization of code, or improper dispose methods. I read a bit on all and made some changes that I hope would fix it, but the problem persists. The only things that cause code serialization in the designer are now display options, such as font, position, size, color, etc. The dispose method was also changed, so that its components are disposed of properly, etc. These things were already done to some extent but I went back and double/tripple checked them to make sure they were correct, and even made some small adjustments just in case. The end result is the same though, the IDE will crash.

The memory dump translated via WinDbg.exe.

FAULTING_IP:

+0

00000000

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)

ExceptionAddress: 00000000

ExceptionCode: 80000003 (Break instruction exception)

ExceptionFlags: 00000000

NumberParameters: 0

FAULTING_THREAD: 00000d2c

BUGCHECK_STR: 80000003

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT

PROCESS_NAME: WindowsApplication4.vshost.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.

MANAGED_STACK:

(TransitionMU)

0012F458 793D424E mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int64, Boolean)+0x2e

0012F470 793D4193 mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+0x23

0012F480 793D420E mscorlib_ni!System.Threading.WaitHandle.WaitOne()+0xa

0012F484 00D5059A WindowsApplication4_vshost!Microsoft.VisualStudio.HostingProcess.EntryPoint.Main()+0x2a

(TransitionUM)

LAST_CONTROL_TRANSFER: from 7c90e9ab to 7c90eb94

STACK_TEXT:

0012f148 7c90e9ab 7c8094f2 00000001 0012f174 ntdll!KiFastSystemCallRet

0012f14c 7c8094f2 00000001 0012f174 00000000 ntdll!ZwWaitForMultipleObjects+0xc

0012f1e8 79f8ead4 00000001 0012f438 00000001 kernel32!WaitForMultipleObjectsEx+0x12c

0012f250 79f17522 00000001 0012f438 00000001 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f

0012f270 79f17493 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateAptStateWait+0x3c

0012f2f4 79f1732f 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateWaitWorker+0x144

0012f344 7a07b49c 00000001 0012f438 00000001 mscorwks!Thread::DoAppropriateWait+0x40

0012f448 793d424e 00000000 00000000 0012f4ac mscorwks!WaitHandleNative::CorWaitOneNative+0x14e

0012f490 79e88ee4 0012f560 00000000 0012f530 mscorlib_ni+0x31424e

0012f510 79e88e31 0012f560 00000000 0012f530 mscorwks!CallDescrWorkerWithHandler+0xa3

0012f650 79e88d19 00a17500 0012f72c 0012f6e0 mscorwks!MethodDesc::CallDescr+0x19c

0012f668 79e88cf6 00a17500 0012f72c 0012f6e0 mscorwks!MethodDesc::CallTargetWorker+0x20

0012f67c 79f084b0 0012f6e0 35d2bfe2 00000000 mscorwks!MethodDescCallSite::Call+0x18

0012f7e0 79f082a9 00a17498 00000001 0012f81c mscorwks!ClassLoader::RunMain+0x220

0012fa48 79f0817e 00000000 35d2b232 00000000 mscorwks!Assembly::ExecuteMainMethod+0xa6

0012ff18 79f07dc7 00400000 00000000 35d2b7ae mscorwks!SystemDomain::ExecuteMainMethod+0x398

0012ff68 79f05f61 00400000 35d2b776 00000000 mscorwks!ExecuteEXE+0x59

0012ffb0 79011b5f 0012f384 79e70000 0012fff0 mscorwks!_CorExeMain+0x11b

0012ffc0 7c816d4f 00000000 0012f384 7ffdf000 mscoree!_CorExeMain+0x2c

0012fff0 00000000 79011b2b 00000000 00000000 kernel32!BaseProcessStart+0x23

STACK_COMMAND: ~0s; .ecxr ; kb

FOLLOWUP_IP:

mscorlib_ni+31424e

793d424e 3d80000000 cmp eax,80h

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: mscorlib_ni+31424e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mscorlib_ni

IMAGE_NAME: mscorlib.ni.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 445b8d66

FAILURE_BUCKET_ID: 80000003_mscorlib_ni+31424e

BUCKET_ID: 80000003_mscorlib_ni+31424e

Followup: MachineOwner

--------

After looking at that for a while with some help, I have decided I do not really know what is going on. I first thought it may be something is not being correctly disposed of during garbage collection and an object is being referanced illegally, but I do no think that should cause the IDE to crash! I am not thinking that maybe it is a threading issue, but I am not sure about that.

Is there anyone out there who knows how the IDE works well enough to give me a good direction to look in, in order to fix this problem. I do not know where to start anymore. All the things I thought it was in the beginning seem to not be it.

And just as an asside, the crash does not occure on my machine or on my version of the IDE alone. It also occurs on other machines and has caused the profesional version of VS 2005 to crash also.


Thanks for any help.

Isaac

--




Answer this question

Control change causes IDE to crash.

  • PaulKotlyar

    It is fixed. After looking at that dump and deciding that what it was telling me was that there is a disposed of object being referanced I wrote a test app that would create, modify, display and dispose of my control many many times. This caused a memory leak. I first thought the memory leak was related to data object that are being created in the control, but after making sure they were all being disposed of correctly I was still getting a memory leak. I altered the order in which I was calling dispose in the test app, and instead of a memory leak I got an exception. The exception was that another thread was trying to access the disposed of tree. I then realized that in certain circumstances a timer is created in the control, and I was not adding that timer to the component container, so it was not being disposed of correctly in the dispose method. This is of course not ever a good idea, because now when the timer event is raised it referances an object that has been disposed of. Why this was causing the IDE to crash, and not catching the exception and letting me know what was going on is a mystery to me, but I guess it is harder to catch all the stupid mistakes that users make than I can possibly imagine. So, the answer to the question is,

    Your timers are not being disposed of stupid.

    The moral to the story is, when you are writing a control, make sure you are putting all the components in the component container so it is cleaned up correctly when the control is diposed of.

    Isaac
    --


  • Control change causes IDE to crash.