I have got a minigame.exe which crashes at some point inside the game. It does not show any error message and it just says Not Responding. I am using Win 7. I want to identify the crashing point and try to fix the games problem. I think the problem might be caused due to a specific DLL imported by the executable. However, I have no clue about how to find out that specific assembly line and try to patch the executable with OllyDBG.
With the information given, this answer would need a full tutorial style, which is considered as too broad for this site. But the first step, finding out what type of crash it is and where it occurs can be explained.
I'll use WinDbg as the debugger, since I'm not familiar with OllyDbg. It is is part of the Debugging Tools for Windows and it's freely available. Install the versions, x64 or x86, that matches minigame.exe.
Start WinDbg, use the correct bitness
Run minigame.exe under WinDbg (File/Open executable). It will stop at the initial breakpoint.
Set up the symbols, at least .symfix c:\debug\symbols and .reload. This will download information needed to construct the callstack.
Continue running the application with g
Reproduce the issue / wait until it crashes
When WinDbg stops,
create a crash dump with .dump /ma c:\debug\minigame.dmp so you can analyze it later, e.g. for asking questions here, so that you needn't reproduce the bug again.
get information about the exception with .exr -1
switch to the thread that caused the exception with ~#s
look at the callstack with k
Now you should have a better understanding of the crash, perhaps enough to apply a patch, maybe not. At least it's a better starting point for further exploration.
Related
I'm trying to use LabView to operate a ThorLab CS235CU camera. However, so far I haven't had any success using LabView to operate it, despite searching the provided thorlabs and national instruments documentation and google for an answer all week. I started by trying ThorLab's VIs that came with their software, but anytime I run a script it returns the following error:
Error 1386 has occurred at Invoke Node. In the provided "simple image aquisition" VI, this error occurs at 3 locations (steps 2, 3, and 4) before deleting the rest of the script, if run with execution highlighted. National Instruments has 3 suggested fixes on their website: unblocking DLLs manually, which seems unrealistic given I don't know what is causing this error; running LabView as an administrator, which I had been doing from the beginning and didn't help the issue; and creating a configuration file, which I tried but did not work. I put it in C:\ProgramFiles\National Instruments\LabView 2020 as well as C:\ProgramFiles(x86)\National Instruments\LabView 2020, but the error still occurs. I'm very new to using LabView and couldn't begin to explain why this error is occurring, so anyone that can or knows how to help, please do.
It seems that you didn't set up the ThorLabs driver properly one way or another. Often it is the manufacturer's installer that must be run first (with LabVIEW turned off) and eventually you'll find the according driver/dll wrapper VIs (also referred to as LabVIEW-Driver) in some arcane subdirectory like <Program Files>\ThorLabs\<Product>\Drivers\Labview\...
It might make sense to copy that directory to your myProject\drivers\ Folder and the simple image acquisition.vi to something like myProject\examples and work your way from there. Also make sure you're using LabVIEW 32bit since few third-party drivers come in 64bit.
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
I rename a VB.NET 2010 project and the IDE crash over and over.
I open another project and same result, after a few seconds or if I open Form1.vb the IDE crash.
And the worst part is there's no info about on the Error window.
The only that I can see as an error code is 0xC0000005
Is the only program crashing on my PC so I have my doubts about a hardware issue.
How can I figure out what is happening?
Can somebody give any clue?
Thanks.
First off, take a look at this question where the answer does a good job of explaining the OXC0000005 error, and all that it encompasses.
Second, look at what has changed on your system since the last time you were able to successfully run Visual Studio. I have seen a few cases where a bad windows update was the cause of a user receiving this error. If you have installed updates since the last time you were able to run VS without error, you may want to uninstall those updates and try VS again. If VS works, begin to re-install the updates 1-by-1, testing VS between every update, to determine which update caused the issue.
I tried the above solution,but unfortunately there is no difference in behaviour.So kindly suggest how to proceed further.
Regards,
Ranjan VijayKumar.
Well you have a crash of some kind, not a WiX issue. If the install didn't fail, then you just have a crashing app. Tell someone what the exception is, the actual error message. Add some debugging to your program and perhaps try/catch exception handling and tracing to see how far it gets and where it crashes. For debug purposes, have it show a message box as the first thing it does so you can see that it loads and has no missing dependencies. Verify in your code that the things you are doing are actually working etc. I'm guessing it's been voted down most likely because it's not a WiX question at all - it's just your code crashing or a missing dependency for which have supplied no data at all.
See the Wix samples for how to create a shortcut the proper way.
A couple of more links:
Wix Toolset Manual Table of Contents
How To: Files, Shortcuts and Registry
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?