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
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
I've created a C-Watchface on Cloudpebble (which works fine). I'm refactoring it to make the code cleaner.
But I'm getting this Error after the Installation:
[FEHLER] ault_handling.c:78: App fault! {1030da8e-9563-4db9-a08f-b8d6d274e8dd} PC: 0x805ea85 LR: ???
Is there a way to get a Human Readable Error Message? Do I have to use the SDK for that?
Debugging on Pebble is not an easy task sometimes.
What you're experiencing is PebbleOS telling you that the crash was your app's fault, and that the OS has been a good little boy.
Usually what this means is that you are referencing a NULL pointer. I'd recommend using APP_LOG throughout parts of your code to check your pointers and make sure you are not destroying anything if you're still using it.
If you are able to break away from the wool sweater of CloudPebble, which keeps you warm but is always a bit itchy, you can use gdb to set breakpoints and do much more thorough debugging.
Read more here on common runtime errors, or read more here for gdb.
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.
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.
A WPF application. Debugging. Stop on break point.
After few seconds Visual Studio (2008) spontaneously aborts the application execution.
It is never mind what I do after stop on break point: even if I do nothing.
With very simple test WPF application everything is OK with debugging.
Any ideas?
When an application aborts that quickly without warning it's usually the result of a stack overflow in the process. This makes it difficult (if even possible) to do tear downs operations like bringing up Dr Watson.
One thing I didn't quite understand is if the application or VS is suddenly stopping.
If it's the application there is likely a StackOverflow occurring in such a way that VS can't trap the exception. Try disabling Just My Code debugging, turn off implicit function evaluation and break on first chance exceptions. That should hopefully help reveal the problem.
The problem was solved.
To solve the problem the debug settings must be changed:debug->exceptions: and check on exceptions boxes (I checked on C++ and CLR).
(source: ggpht.com)
Result: I can see exception that I didn't see before and I can normally debug my application.
The reason was incorrect vcshost.config file name (my fault).