Visual studio 2010 first chance exception KernelBase.dll : 0x000006BA: Win32 exception - visual-studio-2010

I am getting this on a build right after the line that says this:
Loaded 'c:\Windows\SysWOW64\msimg32.dll', Symbols loaded (source information striped).
That is the last thing I see when the program DOES NOT open in debug.
When it DOES open in debug I get the following after that line:
First-chance exception at 0x75f0c42d (KernelBase.dll) in xxx.exe: 0x000006BA: The RPC server is unavailable.
Most of the time I get the first case so I have to keep stopping the debug and starting it until the program comes up with the 2 case.
I have tried setting a break point for that exception from info I found on here already but even if i comment it out, i still get the first case with no program opening for debug.
I have tried using Microsoft Symbol Servers and without.
I am not sure what else to try as I am only getting the program running about 1 tries in 6.

Related

Why Visual Studio abruptly stops the program and shows error #include gtkmm.h not found

I've been trying to run a pre build program by my friend which includes vcpkg package and it runs well but failed abruptly saying that the gtkmm.h header file not found. I think I was searching for some debugging settings and misplaced something which killed the whole debugging process.
Can anyone please tell me about the mistake I've been doing that the program keep showing the error for gtkmm

exception thrown when debug single stepping vs2017

I'm trying to single step (F10/F11) through my code, but it doesn't work. It always throws a "Access violation writing location 0x0000" exception from within ntdll.dll.
When running the program straight it works fine. The exception is only thrown when single stepping. It doesn't matter where in the code the single step occurs I can place a BP at random somewhere in the code, run the program to the BP and then single step from the BP. That hit's the exception.
When starting the program in single step (F10) I can't even execute the first statement.
Does anybody have any ideas?
When disabling native code debugging it works. However without native code debugging you can't debug unmanaged code anymore.
That makes work a bit akward. When debugging code within a unmanaged DLL you have to enable "native code debugging" set the BP inside the DLL code. Single stepping within the DLL works. Once you're done and go back to managed code you have to disable "native code debugging".
Weird.

Runtime error in Release mode in OpenCV 2.4.2 under VS2010?

Compilation of my code in both modes debug and release is successful. Debug mode execute and works fine, but when i execute release mode, it says "the application was unable to start correctly 0x80000003".
What is this error and why debug mode works fine but not release.
DLLs for debug and release are present in the same directory name "bin". "lib" for both modes also placed in the same directory.
I tried to solve it many ways but not succeeded ? Guide me how to solve this issue? Thanks.
why debug mode works fine but not release
Thre can be many reasons why one build works while another doesn't. The shape and size of data structures can be different because of #ifdef or because the compiler emits different code, the code being executed can be different - again because of constructs like #ifdef or because of the code the compiler is emitting.
That can matter when you've got code with a bug in it. Let's say you've got a bug that miscalculates the length of an array (or the size of a structure or whatever). You do some pointer arithmetic and write some data into memory using that pointer - only you're writing to the wrong place. Whether that mistake breaks your program may depend on what was in the memory you overwrote.
If you're lucky your program crashes almost immediately because what you overwrote was important to some code executed immediately after your bug. If you're only a little bit lucky your program crashes some time later in a completely different part of your program because what you overwrote was important to code far away from your bug. If you're really unlucky your program doesn't crash at all until several years later when a completely unrelated change moves things around in memory so now what you are overwriting suddenly is important.
There are lots of other possible causes of what are sometimes called Heisenbugs
What is this error
One place to look for errors like 0x80000003 is the file WinError.h which you'll find in the SDK you are using (either the one that came with Visual Studio 2010 or one you installed later). Look in WinError.h and you'll find that that E_INVALIDARG is defined to be _HRESULT_TYPEDEF_(0x80000003L).
That doesn't necessarily help though because we we don't know enough about what is returning that error or why it is returning that error or even that your 0x80000003 is in fact an E_INVALIDARG - it could be some other error with the same value, or some piece of code mis-using E_INVALIDARG or something else.
Another possibility is that 0x80000003 is a hard-coded breakpoint exception being thrown - most likely because your program has got to one of those "this should never happen" places where the only thing that makes sense is to throw an exception and crash. If you look in NtStatus.h (in the same place as you found WinError.h) you'll find that STATUS_BREAKPOINT is defined to be ((NTSTATUS)0x80000003L)
how to solve this issue
The trick is to figure what is causing the 0x800000003 (and where in your code it is happening) so you can narrow down why it is happening. Most likely it's an exception but why jump to conclusions?
You can run a release build inside the debugger just as you would run a debug build - that is, build the code using the Release target and then press F5 or Debug | Start Debugging. Look in the Output Window and you may see some information that will help you interpret the error.
You can also use the Debug | Exceptions menu to add a new Win32 Exception with the value 80000003 and set that up to break when thrown rather than to break when unhandled. That way you should stop in the debugger when that exception is thrown (if it is in fact thrown).
Of course it could be that even running your program within a debugger is enough to change things so your problem doesn't occur.

Visual Studio strange startup exception

For some reason VS was not breaking on exception when running in debug mode, so I followed the advice given here to go to Debug -> Exceptions and enable the CLR exceptions. I now get this error:
System.Globalization.CultureNotFoundException occurred
Message=Culture is not supported.
Parameter name: name
uploads is an invalid culture identifier.
Source=mscorlib
ParamName=name
InvalidCultureName=uploads
StackTrace:
at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
InnerException:
This error occurs on startup, but only some of the time.
The advice here then recommends that I do the exact opposite and uncheck the debug the CLR option, but I am then back to square one! A poster suggests that it is a bug, but the post is two years old, so surely that has been fixed by now.
I am not using globalisation.

Error in Output Window - Managed' has exited with code -2147023895 (0x800703e9)

I am unable to run a windows application in Visual Studio 2008. Program has been working fine until I started getting an error in the Output Window - "
The program '[2260] MUS3.vshost.exe: Managed' has exited with code -2147023895 (0x800703e9). " This happens even before execution of the code begins.
Any help ? Thanks in Advance
I am placing the entire error here
'MUS3.vshost.exe' (Managed): Loaded
'D:\Documents and
Settings\Administrator\Desktop\MUS
TEMP\trunk\Dev\Source\Source\Binaries\MUS3.exe',
Symbols loaded. Ignoring managed
exception from unknown thread.The
program '[2260] MUS3.vshost.exe:
Managed' has exited with code
-2147023895 (0x800703e9).
Hell, this is not quite an answer, but at least it might help someone. I met with something like the above problem, but in Visual Studio 2005 Pro SP1. Everything had been working and then suddenly nothing worked.
I tried all sorts of different things and ideas... even tried simply creating a new windows application and trying to start it in debug mode (same thing happened, same message appeared - my heart broke seeing the following output again and again from the VS debug output window:
'WindowsApplication1.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Process is terminated due to StackOverflowException.
Ignoring managed exception from unknown thread.The program '[1856] WindowsApplication1.exe: Managed' has exited with code -2147023895 (0x800703e9).
Even thought that i maybe messed the .NET versions on my computer. Well, but at least in my case things finally were much simpler, and maybe this applies for my case only (silly me) - but somehow in Application Properties -> Debug tab, the radio button named "Enable unmanaged code debugging" was unchecked. After checking it, more "libraries" seem to be loaded, albeit with no symbols....
and...
magically the program is started normally and the debugger actually steps in on a breakpoint. i don't quite know or suspect why this think worked out like this - any suggestions are welcome!
This Error occurred mostly at that when you move your code from one version of visual studio to another latest version.
In older version if you are using latest framework like 4.5
At initial stage Warning is !(Your Application Not Target the Exact Framework)
Then First you should target the Framework(Click on Project rather than Solution go to properties ->Application set your framework)
Then clean and rebuild. If not working then You should use a Window Form which not manipulate any data from DataBase or create a new folder, in that folder create a new Form then this from Run through the main function. I hope this will work
78692110
if you're using .net 2013, then go to project, then at the property windows go to references and add the references for the Microsoft ADO Data Control ,it will work now

Resources