SQLite.Interop.dll崩溃，没有任何解释

Question

I have a .net winforms application that is distributed to several computers and it uses a local sqlite database.

This application seems to run fine when I start it and it communicates fine with the sqlite database.

Unfortunately after some time the application crashes and says nothing more than the following in the event log:

• System

• Provider

  [ Name] Application Error

• EventID 1000

  [ Qualifiers] 0

  Level 2

  Task 100

  Keywords 0x80000000000000

• TimeCreated

  [ SystemTime] 2015-09-12T05:04:50.000000000Z

  EventRecordID 11046

  Channel Application

  Computer COMPUTERNAME

  Security

  • EventData

  APP.exe 1.4.0.0 55f3427b SQLite.Interop.dll 1.0.89.0 526c2665 c00000fd 0003ad7c e3c 01d0ecda7737ba11 C:\\Program Files (x86)\\APPFOLDER\\APP.exe C:\\Program Files (x86)\\APPFOLDER\\x86\\SQLite.Interop.dll cb1e1c14-590b-11e5-80ce-00155d8378f5

---

I have now added some exception reporting in the hope that I get more information. But I'm not sure that this will be enough....

Also, I'm not sure what I can do to trigger the problem...

---

This may not be related but someone else even got a screenshot of another exception that occured:

CLR20r3 In System.Data.SQLite => I looked this up and found a SO post: Program Stopped working, Problem Event Name: CLR20r3

So I modified the app.config to add :

    <startup useLegacyV2RuntimeActivationPolicy="true" >  
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>

Not sure if this has helped since I can't reproduce this problem.

Just wanted to add this info in case someone recognizes this as related...

---

Has anyone seen something like this before and what is the best course of action?

PS. the application talks to sqlite every few minutes via telerik data access (aka telerik openaccess) => it's just a ORM like EF.

Answer 1

Would you be able to attach a debugger such as Windbg or Remote debug with Visual Studio ? That way you can get more information about the exception (if there is one) that is thrown.

In order to debug this more thoroughly, I would pull out the code that communicates with the database and create a small application that runs that section over and over again. Since you said it takes a few minutes to actually communicate with the DB and since we're getting the error at the interop assembly, then it would be best to stress test that.