Hi we have a product of a C# WPF application riding upon a C++ engine.
Occasionally (more often than we would like) we have to debug the whole stack.
Recently I started having a crash occur in the application on the creation of a connection.
connection = Database.DefaultConnectionFactory.CreateConnection(connectionString);
yes I have tried creating a connection by this method. But it produces the same error.
var factory = DbProviderFactories.GetFactory(providerName);
connection = factory.CreateConnection();
connection.ConnectionString = connectionString;
We have a SQL CE database for storing...well data.
We access it using EF Code First.
We found in the past we could improve performance by creating ONE connection (it is one file) and reusing the connection.
The app is crashing on me WHEN it creates the connection NOT our code.
I have tried catching Exception or ExecutionEnginException (I could not find FatalExecutionEngineException)
I have also tried reinstalling the various packages related to our EF stack.
All to no avail.
Please help if you have run into this problem or a MS engineer that scours the stackoverflow boards.
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in > >'(our application)'.
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0xd8ed0f68, on thread 0x2330. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
If there is a handler for this exception, the program may be safely continued.
Related
I've been testing the new platform over the last couple weeks and have had trouble with syncing reliability, occasionally getting an error 108 inside the SyncManager.sharedManager error handler. I see from the documentation that error is described as:
“Client file bound in other session (IDENT)” Indicates that multiple sync sessions for the same client-side Realm file overlap in time.
However, I'm not really sure what this means or how to go about debugging it. Any advice?
solved... maybe?: I found there is a logOut() method in the RLMSyncUser class which seems to flush any open sync sessions. I've added this to my error handler which will hopefully reset sync states.
This was an issue with older Realm Object Server versions, but has been fixed since version 1.0.0-BETA-2.2. Please update to a newer version of the Realm Object Server. 1.0.0-BETA-4.2 currently.
I have an ASP.NET application that is using Entity Framework 6 to access data stored in an Azure SQL database. I've run into a bit of a problem connecting to the database as a whole.
If I spawn a new database instance on Azure, start my app in the debugger and step through it, I'll see that it connects without a problem, can access the seed data and all is well (inserts work without a problem, but this occurs whether I change the data or not).
However, if I restart the debugger and at all points after that attempt to connect to the database when my app restarts, the connection will fail. If I set a breakpoint and look at the Context value in the Locals window, I have the following error as the value for all DbSets:
Function evaluation disabled because a previous function evaluation
timed out. You must continue execution to reenable function
evaluation.
Despite having a try/catch around the logic, no exception will be thrown. If I step into/out of/over this, the application will just run indefinitely and never complete.
If I do a rollback to the $InitialDatabase and then re-apply the automatic migration (via update-database), I still cannot connect to the database, however if I delete the database in Azure, spin up a new one, set up the new connection information in the Web.config file and execute all over again, it'll work like a charm one time. After that, it'll fail to work again, despite no other changes to the application.
What's going on here and why is this behavior occurring? If there's an underlying problem here, how could I tell what it is and how can I resolve it?
Thanks!
After making no headway, I rolled-back to a previous version of my code from when it was working fine about three weeks back. I've updated all the logic to match what was in the latest build, I just haven't updated any of the assemblies yet. It's working perfectly fine and connecting every time now, so apparently this is the fault of one of the as-of-yet unidentified dependencies.
If I ever determine which one, I'll update this answer accordingly.
I recently upgraded an application from .net 3.5 to 4.0. Since I did that, with debug settings to break on all exceptions enabled, I've been getting a few of these exceptions each time I start a section of the application that connects to a database using the EF. The exact number is variable; sometimes I only get one, others several in rapid succession.
ReleaseHandleFailed was detected Message: A SafeHandle or
CriticalHandle of type
'Microsoft.Win32.SafeHandles.SafeCapiHashHandle' failed to properly
release the handle with value 0x06AD3D08. This usually indicates that
the handle was released incorrectly via another means (such as
extracting the handle using DangerousGetHandle and closing it directly
or building another SafeHandle around it.)
I never got exceptions like this when targeting 3.5. These exceptions don't have any meaningful call stack attached, all I get is [External Code], denying any easy way to localize where they're coming from. The reason I suspect EntityFramework is somehow involved is that one section of the app uses nHiberate instead doesn't generate any of these messages.
To run down other dependencies that might be involved: In all cases, the ORM is talking to an Sql Compact database MS Sync Framework 2.1 is being used to update the local DB from SqlServer. The Entity framework models have been regenerated with the 4.0 framework, and I upgraded the cache DB to v4.0 as well.
Since there's no call stack I'm not sure if these messages fall into the category of "harmless" errors automatically cleaned up internal to the framework; or if there's an exception eater catching them elsewhere in the application.
This is not an exception, it is a Managed Debugging Assistant warning. You might have gone over-board a bit when you changed the settings to "break on all exceptions enabled". Debug + Exceptions, Managed Debugging Assistants node, untick the "ReleaseHandleFailed" warning. It is off by default.
The MDA catches an old bug that's gone undetected for a while in the AesCryptoServiceProvider class. Backgrounder is here.
Judging from your comment, you are about to make a drastic mistake. You do not solve this by avoiding encryption or compromising your dbase connection security. You accidentally turned on an MDA that's normally off. MDAs in general tend to produce false warnings and many of them are turned off by default. The warning is in fact bogus, releasing the handle failed because it was already released. This happens in the finalizer thread, that's why you don't get a stack trace. And thus can't easily find out what code uses the class in the first place.
The proper way to fix it is to use the Debug + Exceptions dialog properly. Fix the problem you created by clicking the Reset All button. Then click only the Thrown checkbox for Common Language Runtime exceptions. That's what you are trying to debug.
I have a piece of code that uses NSURLConnection to fetch a network resource asynchronously and parse some XML as it streams in. The XML parsing is handled by libxml2 which is available as a framework in the iOS SDK. This works perfectly when I invoke it once, parse the XML and release the resources by calling xmlFreeParserCtxt(ctxt).
My problem is that when I run this same code in multiple threads, all of a sudden i see EXC_BAD_ACCESS pop up which I trace back to the libxml2. Specifically the xmlParserCtxtPtr context which is initialized and used for XML parsing seems to throw the EXC_BAD_ACCESS when I release it after I am done retrieving the resource.
The exception goes away if I do not release this context i.e. call xmlFreeParserCtxt(ctxt).
This leads me to believe that my issues are some how related to libxml framework available in iOS not being thread safe.
Sure enough, I see this when I google the issue:
From: http://xmlsoft.org/threads.html
Starting with 2.4.7, libxml2 makes provisions to ensure that concurrent threads can safely work in parallel parsing different documents. There is however a couple of things to do to ensure it:
* configure the library accordingly using the --with-threads options
* call xmlInitParser() in the "main" thread before using any of the libxml2 API (except possibly selecting a different memory allocator)
So I have two questions:
1.) Is my assumption correct that the version of libxml that I am using is not thread safe and hence causing the issue? Has anyone else seen this?
2.) I know that the iOS bundles libxml2.2.x - would it work if I get libxml2.4.7 and add it to my project? Would that cause any rejections on the app store?
Thanks for your time.
I have this Perl software that is supposed to run 24/7. It keeps open a connection to an IMAP server, checks for new mail and then classifies new messages.
Now I have a user that is hibernating his XP laptop every once in a while. When this happens, the connection to the server fails and an exception is triggered. The calling code usually catches that exception and tries to reconnect. But in this case, it seems that Windows (or Perl?) is catching the exception and delivering it to the user via a message box.
Anyone know how I can prevent that kind of wtf? Could my code catch a "system-is-about-to-hibernate" signal?
To clear up some points you already raised:
I have no problem with users hibernating their machines. I just need to find a way to deal with that.
The Perl module in question does throw an exception. It does something like "die 'foo bar'. Although the application is completely browser based and doesn't use anything like Wx or Tk, the user gets a message box titled "poll_timer". The content of that message box is exactly the contents of $# ('foo bar' in this example).
The application is compiled into an executable using perlapp. The documentation doesn't mention anything about exception handling, though.
I think that you're dealing with an OS-level exception, not something thrown from Perl. The relevant Perl module is making a call to something in a DLL (I presume), and the exception is getting thrown. Your best bet would be to boil this down to a simple, replicable test case that triggers the exception (you might have to do a lot of hibernating and waking the machines involved for this process). Then, send this information to the module developer and ask them if they can come up with a means of catching this exception in a way that is more useful for you.
If the module developer can't or won't help, then you'll probably wind up needing to use the Perl debugger to debug into the module's code and see exactly what is going on, and see if there is a way you can change the module yourself to catch and deal with the exception.
It's difficult to offer intelligent suggestions without seeing relevant bits of code. If you're getting a dialog box with an exception message the program is most likely using either the Tk or wxPerl GUI library, which may complicate things a bit. With that said, my guess would be that it would be pretty easy to modify the exception handling in the program by wrapping the failure point in an eval block and testing $# after the call. If $# contains an error message indicating connection failure, then re-establish the connection and go on your way.
Your user is not the exception but rather the rule. My laptop is hibernated between work and home. At work, it is on on DHCP network; at home, it is on another altogether. Most programs continue to work despite a confusing multiplicity of IP addresses (VMWare, VPN, plain old connection via NAT router). Those that don't (AT&T Net Client, for the VPN - unused in the office, necessary at home or on the road) recognize the disconnect at hibernate time (AT&T Net Client holds up the StandBy/Hibernate process until it has disconnected), and I re-establish the connection if appropriate when the machine wakes up. At airports, I use the local WiFi (more DHCP) but turn of the wireless altogether (one physical switch) before boarding the plane.
So, you need to find out how to learn that the machine is going into StandBy or Hibernation mode for your software to be usable. What I don't have, I'm sorry to say, is a recipe for what you need to do.
Some work with Google suggests that ACPI (Advanced Configuration and Power Interface) is part of the solution (Microsoft). APM (Advanced Power Management) may also be relevant.
I've found a hack to avoid modal system dialog boxes for hard errors (e.g. "encountered and exception and needs to close"). I don't know if the same trick will work for this kind of error you're describing, but you could give it a try.
See: Avoiding the “encountered a problem and needs to close” dialog on Windows
In short, set the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows\ErrorMode
registry key to the value “2″.