Let me state upfront that I truly appreciate any assistance on this issue.
I have a C# (2.0) application. This is relatively simple application that executes stored procedures based on an XML file that is passed as a command line parameter.
We use it as a tool to call different stored procedures. This application does some logging and for the most part works very well.
The application reads the stored procedure name and parameters from an XML file. It sets up a connection string and SQL Command object (System.Data.SqlClient.SqlCommand).
Then it runs the stored procedure with the ExecuteReader method.
Unfortunately on a handful of occasions this application has generated the following error:
“Application popup: StoredProcLauncher.exe - Application Error : The instruction
at "0x7c82c912" referenced memory at "0x00000000". The memory could not be "read”
This error has appeared on multiple servers so it must be a code issue.
It seems that when our production server rolls a certain number it belches out this memory error.
The problem is I don’t see this issue on development. I can’t replicate it so I’m stuck.
Is there any way to simulate this error. Can I fill up the memory on my local PC somehow to attempt to replicate this error?
Does anyone know some common coding issues that might result in an error like this?
Does anyone have some rope I can borrow?
One way to do this is to wrap the offending code in a try catch block and writing the stack trace and error message to the windows application event log, text file, email, etc.
This will give you some line numbers and additional information.
Also note, you may need to deploy this in debug mode or at least copy the .pdb file with the application exe/dll so it can get the debug symbols. Can't remember off the top of my head how that works, but I think when you deploy in release mode you may loose some valuable debug information.
The instruction at "0x7c82c912" referenced memory at "0x00000000"
This is an access violation:
An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value.
Why does your program have unmanaged/unsafe code? For doing what you described it needs no native code.
Alas, the code crashes and now is not the time to wonder how is ending up calling native code. To solve the issue you're going to have to catch a dump and analyze the dump. See Capturing Application Crash Dumps. There are tools that specialize in this, like breakpad. there are also services that can help you collect and track crashes generated from your app, like crittercism.com or AirBrake. I even created one for myself and made it public bugcollect.com.
Related
I have a very simple Unity WebGL project that I am trying to connect to a SQL Server database from.
When I run the project in the Editor, it works fine.
When I run the WebGL build, as soon as I try to open the DB connection I get an "Out of memory" pop-up and this error in the console:
PrototypeProject.loader.js:1 Cannot enlarge memory arrays. Either (1)
compile with -s TOTAL_MEMORY=X with X higher than the current value
2144141312, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows
increasing the size at runtime, or (3) if you want malloc to return
NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0
My understanding is that the advice included in the error is out of date because allow memory growth defaults to enabled and there is no total memory setting in recent versions of Unity. I can't see why (3) would be a sensible thing to do
I know the problem is triggered (every time) by connection.Open because the first of these debug lines is output but the second is not
SqlConnection connection = new SqlConnection(connectionString);
Debug.Log("Calling connection.open");
connection.Open();
Console.WriteLine("Connection open");
One option would be to stop trying to connect to the database directly and call a web service which does the database work instead. Yes, I know that having a three-tiered architecture is a better design in any case - this was approach was used in a (failed, clearly) effort to prototype something quickly
However I really want to understand what's going on here in case I might have similar issues in future. I know that SOMETHING has to be the tipping point that runs you out of memory, but just opening a connection doesn't intuitively (but maybe I'm wrong...) seem like it should be a massive memory hog and I can't see any noticeable difference when using the Profiler in the editor
Does anyone have any experience in troubleshooting SQL Server connections in particular, or memory issues in general, in WebGL that might be relevant to understanding and avoiding this behaviour?
The answer was much more rudimentary than I expected - it's just not possible to use SqlConnection in a WebGL build because SqlConnection in turn is trying to use Sockets that WebGL builds do not have access to
Exactly why this manifests as an "out of memory" error, or why the Unity Editor couldn't be a little bit more helpful and warn you that you are using classes that are not going to work when you start a WebGL build, I do not yet understand...
I am not a programmer. I have some software at work that keeps crashing on me. I used the Visual Studio debugger last time it crashed and found out it was unhandled exceptions.
The first unhandled exception is at 0x0048ADF0 in Cyclone.exe and is an Access violation writing to location 0x00000003.
My research leads me to understand that this is the program trying to write to memory that the process doesn't have permission to.
When running the debug in Visual Studio, after the access violation exception there is a long list of Unhandled exceptions similar to this "...at 0x776C016E (ntdll.dll) in Cyclone.exe: 0x00000000: The operation completed successfully." with different addresses.
Is there any way I can fix this without being a programmer? Some sort of modification to the app files or settings, or a tutorial or something.
No, there is no way. It's not different from asking if you can drive a car without knowing anything about driving.
Sounds like you need to report the problem to the person or company who provided it. What you need to do, however, is give them enough information to understand the problem and fix it. This includes:
what version of their program are you running
which computer operating system (e.g. Windows) and which version (e.g. 7)
precisely what steps you have to take to make the error occur
whether you have changed anything recently, e.g. by installing Windows Updates or changing your anti-virus protection
precise details of any error messages you see, ideally by copy/paste or by providing a screenshot of the erro
anything else you think might help them to help you
Be prepared for them to ask you additional questions, or try some tests to help figure out the cause and a way to solve it.
Your research sounds about right but I don't think there is much anyone here can do to help (unless they happen to work on the application).
Your best bet would be to look for a "Help" or an "About" screen and contact the people who wrote it with this information
I have an issue with the sqlite3_mutex_enter(v->db->mutex) error message on an iOS application.
The case is the following: I developed an application that is performing a sync on the application in the background while starting up. All SQL Statements that invoke writing to the DB are protected using a NSLOCK and are unlocked after the finalize.
Now the problem is, that the Application User can start working with the application while the sync is still ongoing. Sometimes I do get now an sqlite3_mutex_enter(v->db->mutex) when something is done on the DB level, sometimes it simply works. The cases where this error appears is mainly in read statements.
Do you have any ideas when the sqlite3_mutex_enter(v->db->mutex) error can show up? All statements are finalized properly. Something really weird is, that the SQLITE DB tries to close itself even if there is no command that tells the DB connection to close.
The statement sqlite3_mutex_enter(v->db->mutex) occurs only inside sqlite3_reset. An error in this place is likely to be caused by an invalid statement pointer, probably one that is already finalized.
I've got a crash in our app which I can't debug as one of our partners has seen fit to use truly horrible 'CodeMeter' to encrypt their DLL. CodeMeter licensing prevents all attempts to debug an app containing a CodeMeter encrypted DLL and even seems to cause MiniDumpWriteDump called from an unhandled exception filter to fail (this technique works without this DLL loaded). The crash only happens when the encrypted DLL is loaded into the process.
I'm going mad trying to debug this and establish whether it's the encrypted DLL that's crashing, and if so how I can provide adequate diagnostic information to our partner to solve this.
Any suggestions - perhaps some manual stack and module walking code I could call from my unhandled exception filter?
Does CodeMeter have build settings that will allow our partner to produce a build that is still encrypted and licensed but doesn't sabotage debugging so aggressively?
Just to be clear in case there's any doubt, I'm not trying to hack the licensing, just diagnose this crash.
I've used some stack walking code that works well that can be called from an SEH or unhandled exception filter by passing in the CONTEXT record passed to the exception filter.
The addresses in the stack and the potential addresses in the first few exception parameters can be interpreted using SymFromAddr in DbgHelp including the module handle. Add to that a log of the module file names and module handles for interpreting which DLLs the stack addresses relate to.
This particular crash was a Visual C++ exception. The type of the exception is revealed by looking up the address of one of the exception parameters using SymFromAddr.
Raymond Chen's blog has some code for finding the type of a Visual C++ exception from the exception parameters but I couldn't get this to work for me for some reason (probably my own error).
I have a WinForms application in which I want to be able to provide an HTML editing feature. So I've translated Lutz Roeder's HTML Writer from C# into VB.NET, and converted it from a windows form into a Custom User Control, which is now hosted in an MDI child form.
It all works fine until I close the parent MDI, in which case it crashes, and I cannot trap the exception.
I've isolated the editor control into a little vanilla WinForms app that doesn't do anything else, and verified that the problem still occurs.
I've also switched on Unmanaged Code Debugging (I'm using VS2010, compiling for x86 and Framework 3.5), and all I get is this:
Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.
The only thing other thing I've noticed is that if I leave a long interval after opening the form containing the editor, it doesn't crash.
What I'd really appreciate is some ideas about how to go looking for this problem. It may be of course that I've made a mistake in the C# to VB conversion, but I'm struggling to know where to look.
Edit:
I've run the app with the debugger attached, and it doesn't give me anything useful.
All I get is the Windows 'Application has stopped working' message, with this in the problem details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: HtmlEditorMdi.exe
Application Version: 1.0.0.0
Application Timestamp: 4cfb74c7
Fault Module Name: mscorwks.dll
Fault Module Version: 2.0.50727.4952
Fault Module Timestamp: 4bebd49a
Exception Code: c0000005
Exception Offset: 000022b5
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 2057
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I can see that it's an access violation, but even if I go Debug > Exceptions > Win32 Exceptions, and tick c0000005, I don't get anything useful when it breaks - just 'no source available'.
The first message you quoted is produced by the Windows heap manager when it discovers that the internal heap structure is destroyed. It displays that diagnostic when it sees that a debugger is attached. The 2nd quoted block is what happens when it bypasses the diagnostic (no debugger attached), it bombs on a hardware exception when it tries to release memory in the corrupted heap anyway.
The trouble with heap corruption is that the real damage is done a long time before the diagnostic is generated. You can see a stack trace leading up to the diagnostic in the Call Stack window, you'll need to enable the Microsoft symbol server to get meaningful symbols for the Windows functions. But it won't tell you anything useful about the code that really caused the damage, that requires a time machine.
This kind of heap corruption is invariably caused by unmanaged code. The AccessViolation exception is a well known scourge to C/C++ programmers and a very large reason why managed code became popular. While Lutz' source code is all managed, it contains a lot of P/Invoke and COM interface declarations. There is no good way to debug them, you don't have the source code.
Getting one of those declarations subtly wrong when you converted them to VB.NET is certainly one way this could happen. It could also well be that the bug was always there but reared its ugly head just now. Lucky you. Btw, I don't think the code is 64-bit clean, force it to run in 32-mode for a possible quick fix. For your main EXE project: Project + Properties, Compile tab, scroll down, Advanced Compile Options, Target CPU = x86. This is only relevant if you run on a 64-bit version of Windows.
Other than that, I'd recommend you just use the C# project as-is. Mixing languages in a solution is a very well supported scenario in .NET.
The windbg debugger is the "big gun" for this sort of problem. It can frequently give you clues by telling you about handled exceptions etc. The only problem with it is that it's not easy to use and has a very high learning curve.