I am debugging the live process (not dump) of PresentationHost.exe. It used to works fine, but suddenly few days ago I get the above error message. !Threads, !pe, virtually all SOS command doesn't work.
All I remember is that I installed Visual Studio 2010 and .NET framework 4.0 before I'm getting that error. Is it related?
UPDATE:
I myself can not reproduce the problem I was having. Probably I was debugging 32 bit process with 64 bit debugger, or .NET 4 process with .NET 2.0 SOS, or vice versa, or combination of both bitness and DLL version.
Apologize that this question may not valid.
When are you trying to issue the command?
This error is quite common when attempting to issue SOS commands before the CLR was fully loaded.
You could attempt to break right after the CLR had finished its initialization procedure. In order to break at that point, you could place a breakpoint in the following manner: bp clr!EEStartup "gu". This will cause the debugger to break on the EEStartup function, and continue execution until the function completes.
When the debugger breaks on that breakpoint, you should be able to issue your SOS commands.
Related
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 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.
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 was wondering if somebody could help me here.
I'm looking after some legacy code written in VB6. I made some updates to this code, just to remove some redundant pieces. I tested this on my development machine before making an exe - it ran fine, no problems (happy days).
I created an exe on the same machine and I am now getting the following errors when I click on 2 of 2 command buttons:
1. Run time error '53' - File not found --- this message appears without a dll reference.
2. Run tim error '91' - Object variable or with block variable not set.
So, since the code ran fine before the exe was created, would you say this is an environment problem - dll's missing, etc...
I'm assuming exe's require different references to do the same job as the application before it is made into an exe.
I'm a novice when it comes to VB6 and I'm not really too sure about what's going on under the hood when these errors pop up.
Thanks.
I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.