none
BEX start-up crash in clr.dll with select users modify/update their user.config RRS feed

  • Question

  • A very small number of users of application I develop are experiencing a crash when they start-up the application.  It's rare, but people who get it can reproduce the problem very easily.  

    It seems there is a corruption of some sort in the user.config file which is being loaded or read on start-up of the app. The crash is remedied by deleting the user.config, however the problem will come back eventually after a few restarts or days of use of the app. This problem also manifests itself if the user manually modifies the user.config. Curiously, a user was able to also "fix" the problem by adding more characters to the user.config XML and the problem went away. 

    So far, other developers and I have not been able to reproduce the problem in house. We've used these trouble users config files in our own system and they load up fine. We've also added tons of garbage characters to the XML ourselves and the .NET framework deletes the corrupted XML like it should and the app starts just fine. Here is the event log of the crash the users are seeing.

    Problem signature:
      Problem Event Name: BEX
      Application Name: Bria3.exe
      Application Version: 32.6.3273.0
      Application Timestamp: 4e431840
      Fault Module Name: clr.dll
      Fault Module Version: 4.0.30319.235
      Fault Module Timestamp: 4da3fdf5
      Exception Offset: 002b68b4
      Exception Code: c0000409
      Exception Data: 00000000
      OS Version: 6.1.7601.2.1.0.768.3
      Locale ID: 1033
      Additional Information 1: c3f8
      Additional Information 2: c3f80716588849c32d0e7d3fe0086f83
      Additional Information 3: 3086
      Additional Information 4: 30869621ce165f22f2605d8fd1bc8f17

    If any MSFT gurus can decode what this all means it would be very much appreciated. I understand BEX has something to do with Data Execution Prevention (DEP) but I'm unable to disable it for my application. The DEP control panel applet says it's a no-no.

     

    /jip



    Thursday, August 11, 2011 5:02 PM

All replies

  • Yes BEX is related to DEP, it is a Buffer Overflow Exception. You can see more about decoding these kind of messages here.

    http://technet.microsoft.com/en-us/library/cc738483(WS.10).aspx

    I do not know exactly what this can be because of but have some ideas where to look at.

    Are the user.config corrupted or do they look ok? Is there anything that looks like string formatting? Are there "too" large numbers in it? Is it 32/64 bit issue?

     

    Friday, August 12, 2011 2:43 PM
    Moderator
  • The user sent us a crash causing user.config but it appears fine.  I tried substituting it on systems in the office and none of them crashed with it. I've posted it on my skydrive here:

    https://skydrive.live.com/?cid=E75A75F1A1FBFBB5&id=E75A75F1A1FBFBB5%21193#!/?cid=e75a75f1a1fbfbb5&sc=documents&uc=1&id=E75A75F1A1FBFBB5%21193!cid=E75A75F1A1FBFBB5&id=E75A75F1A1FBFBB5%21193&sc=documents

    Nothing in it looks out of the ordinary. Nothing is too large and the xml i think is still valid.

    This user is running 64 bit Win7 but so do the vast majority of our customers and it hasn't been a problem.

    The crash signature points to clr.dll and isn't that a .NET assembly? If so would this mean it's a crash outside of my application code?

     

    Friday, August 12, 2011 9:42 PM
  • Curiously this user says he can cause the crash by opening user.config in VS, selecting chunks of the text, and doing a Format Selection. I tried the same and on my system it goes through it no problem. 
    Friday, August 12, 2011 10:20 PM
  • clr.dll is internal component of the .NET framework. It shouldn't crash from a bad user.config file and I am unable to see what in the config could even cause it.

    I also looked at the config file and nothing obvious that could go this wrong. Even if it is garbage I would say that it shouldn't crash like this.

    I believe you need to be able to examine a machine where the errors occurs on to get more clues. 

    Saturday, August 13, 2011 7:02 AM
    Moderator
  •  

    Hi,

     

    Has your issue been resolved? Would you mind letting us know the result of the suggestions?

     

    Now I will mark an answer, you can mark others that you think to be so useful to your issue.

    If you still have any questions about this issue, please feel free to let me know. We will continue to work with you on this issue.

     

    Have a nice day!


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, August 15, 2011 7:31 AM
  • This issue has not been resolved yet. I'm still working with the affected customer.

    In my skydrive (https://skydrive.live.com/#!/?cid=e75a75f1a1fbfbb5&sc=documents&uc=1&id=E75A75F1A1FBFBB5%21193) you can see an event viewer log of the crash. It only contains the same problem signature I've posted above but you can download and take a look for yourself. 

    I'm going to recommend a .NET remove and reinstall and see if this remedies the situation.

    Monday, August 15, 2011 4:26 PM
  • You can use this tool to verify the presence of files, directories, registry keys and values for the .NET Framework.  It will also verify that simple applications that use the .NET Framework can be run correctly.

    .NET Framework Setup Verification Tool User's Guide

     


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, August 17, 2011 7:07 AM
  • I'll have the user run this utility thanks.

    I'm at a loss of what to look for on this system. Even if I had direct access to it, I don't know what I would look for and troubleshoot. Can someone suggest what to do? What should I put in a test application?

    Wednesday, August 17, 2011 4:41 PM
  • I didn't have a chance to run the utility posted earlier, but the user was able to run Windows update and applied all the latest .NET 4.0 updates and it remedied the crashing issue. We will verify this with other trouble users and see if fixes it for all.
    • Marked as answer by Paul Zhou Wednesday, September 7, 2011 6:40 AM
    • Unmarked as answer by jippers Wednesday, September 7, 2011 11:41 PM
    Monday, August 22, 2011 7:17 PM
  •  

    We've just had a user on XP SP3 report the same crash. The user applied all .NET updates 4.0 updates and they still experienced the crash.

    Here's their crash log:

     

    Event Type:	Error
    Event Source:	Application Error
    Event Category:	(100)
    Event ID:	1000
    Date:		9/7/2011
    Time:		9:22:57 AM
    User:		N/A
    Computer:	UHG224
    Description:
    Faulting application Bria3.exe, version 32.6.2387.0, faulting module clr.dll, version 4.0.30319.235, fault address 0x002b68b4.
    
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: 41 70 70 6c 69 63 61 74   Applicat
    0008: 69 6f 6e 20 46 61 69 6c   ion Fail
    0010: 75 72 65 20 20 42 72 69   ure  Bri
    0018: 61 33 2e 65 78 65 20 33   a3.exe 3
    0020: 32 2e 36 2e 32 33 38 37   2.6.2387
    0028: 2e 30 20 69 6e 20 63 6c   .0 in cl
    0030: 72 2e 64 6c 6c 20 34 2e   r.dll 4.
    0038: 30 2e 33 30 33 31 39 2e   0.30319.
    0040: 32 33 35 20 61 74 20 6f   235 at o
    0048: 66 66 73 65 74 20 30 30   ffset 00
    0050: 32 62 36 38 62 34         2b68b4  

     


    Here's an excerpt of an email describing the problem from the user in question:

    I've installed all updates Microsoft update finds for all
    versions of .net.  I searched for the folder indicated (what I'd imagine
    is the location on Win7) in Documents and Settings/<user>/Application
    Data/Counterpath Corporation/Bria and deleted the Bria folder.  It
    appears to have allowed the program to run once when I deleted it logged
    in as myself then ran the program as the user affected, but deleting the
    folder and attempting to run the program when signed on as the user in
    question does *not* allow the program to run. 

    I've suggested to the user to try installing the .NET 4 reliability update 1 from here http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27014

    Maybe this will fix it?


    • Edited by jippers Wednesday, September 7, 2011 11:58 PM
    Wednesday, September 7, 2011 11:46 PM
  • No, it did not. User still reports crashing. In fact another user explicitly has applied this reliability update and is seeing the crash. The clr.dll version number is in the dump message. 

    Faulting application name: Bria3.exe, version: 32.6.2387.0, time stamp: 0x4de8200e
    Faulting module name: clr.dll, version: 4.0.30319.237, time stamp: 0x4dd234a8
    Exception code: 0xc0000409
    Fault offset: 0x002b6884
    Faulting process id: 0x1a2c
    Faulting application start time: 0x01cc6db1f2d3f3bb
    Faulting application path: C:\Program Files (x86)\CounterPath\Bria 3\Bria3.exe
    Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Report Id: 32dceccb-d9a5-11e0-a439-00a0c6000000


    Thursday, September 8, 2011 4:17 PM
  • It seems that I have found a race condition in clr.dll.

    The user has submitted steps that finally has reproduced the crash on a system. When I get the user.config into a "crashy" state the application will reproduce the above crash signature every time. 

    Now the interesting thing is if I run the application with WinDbg or try running a local build with VS2010 the crash NEVER happens.  Outside a debugger environment crashes every time. 

    Can I get some advice on how to proceed?


    • Edited by jippers Thursday, September 8, 2011 11:18 PM
    Thursday, September 8, 2011 11:18 PM