Search code examples
c#winformsclrbuffer-overflowbuffer-overrun

Buffer Overflow in clr.dll at application start-up


I have two computers. Both work under Windows 7 Embedded and have same version of .Net 4.0 framework installed. My WinForms application works with no issues on one of them but fails at start-up with BEX in clr.dll on another.

Problem Event Name: BEX
Application Name:   Myapplication.exe
Application Timestamp:  5669ec33
Fault Module Name:  clr.dll
Fault Module Version:   4.0.30319.526
Fault Module Timestamp: 4eb3b6b1
Exception Offset:   002b65ec
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7601.2.1.0.320.65
Locale ID:  1033
Additional Information 1:   a835
Additional Information 2:   a835052745ddb3bce091e0cd181de7e7
Additional Information 3:   7cb8
Additional Information 4:   7cb8eec426d05584b36071af9d74719d

What is very "strange"

I was able to find two things in my application that somehow have impact or provoke this problem. First I found exact line of code.. I have few buttons that I manually create manually on UI thread. And if I remove next line my application starts.

btn.Font = new Font("Tahoma", 9, FontStyle.Bold, GraphicsUnit.Point, 0);

Second I noticed that if I use my debug logger which uses StackFrame to find out where log message is coming form, Application will crash with the same error in CLR but at some other place. Not at the line I mentioned above.

My two computers have different RAM. 2GB and 1GB. Application fails on the second one with 1GB of memory. But application iself uses 30 MB and system has ~350 MB of free memory. Could memory be a reason ?

My research for the most part referred me to different hot-fixes issued by Microsoft. I tried them but nothing helped. I also tried to install .Net v4.5 but with the same negative result.

Where else I can start looking for the problem ?

... And yes, this problem does not show up when running application with attached debugger.

Update

I just realised that "Exception Code: c0000409" means STATUS_STACK_BUFFER_OVERRUN. This brings some sense to strange application behaviour that I have but still not clear why it works on one computer but does not work on another.


Solution

  • Solution finally found

    My application uses third party C# library which is actually a wrapper on top of calls to other native library. I decompiled library and realised that calling convention is set to CallingConvention.Cdecl but as I see from Dependency Walker application, all methods in native library has CallingConvention.StdCall

    After changing calling convention and recompiling the library issue disappeared.