is there any way the .net 4 debugging api can somehow corrupt the state of an application during startup?
the issue i have is the following:
if i start my application from within a debugger using the .net debugging api (visual studio 2010, sharp develop 4, mdbg), i get various random access violations.
if i start my application from within a debugger not using the .net debugging api (delphi 2007, windbg with sos extension) everything works fine.
if i start my application directly and later on attach a debugger to it (like visual studio 2010, sharp develop 4, mdbg, delphi 2007, windbg), everything works fine.
if i move back to .net 3.5 and clr 2.0 i have no problems at all.
so what changed from .net 3.5 to 4.0 in the managed debugging api causing my application to throw access violations if started with it?
the application is written in delphi (unmanaged) and c# (managed) using managed vcl to do the interop.
i can hardly give any example to reproduce this issue so i'm aware that answering this question might be impossible, but if someone with more insight to the debugging api can give me a hint in the right direction or could help me narrow it down i'd be very thankful.
Just for fun try and disable the Visual Studio hosting process. In Visual Studio right click on the project, go to the 'Debug' tab, and uncheck the "Enable the Visual Studio hosing process" check box.
We've seen some strange stuff in the managed/unmanaged land on 64 bit systems running 32 bit apps.
Some additional info based on experience: It is important to use the COMPLUS_MDA environment variable (remember to restart VS2010 afterwards), not the MDA registry key. I tried setting the registry key (followed by restarting the computer) as described by the MSDN article http://msdn.microsoft.com/en-us/library/d21c150d, as the article indicated this should have the same result, but that didn't work.
Related
EDIT:
Found issue to be resharper. When I disable it it stop showing errors.
When I start a new Blazor fullstack project from Visual Studio it shows error in IDE. I have looked at Visual Studio displaying errors even if projects build but doesn't seem to help.
I followed the guide on Blazor (https://blazor.net/docs/get-started.html)
But the client side project shows lots of errors
EG:
and more details:
and:
Any one else tried this and know how to fix it?
I am running VS Studio Enterprise 2017 Version 15.8.8
I have installed ASP.NET Core Blazor Language Services.
Everything seems to work as it should. I was able to add new page with external RestAPI calls and all.
Edit:
Updated VS to latests version with no luck
Seems it might be resharper:
https://resharper-support.jetbrains.com/hc/en-us/community/posts/115000554550-ASP-NET-Core-Razor-Pages-page-Cannot-resolve-symbol-
Well. Seems that jetbrains is aware of issue.
It can be found here:
https://youtrack.jetbrains.com/issue/RSRP-469186
Not much to do than disable Resharper for the moment and wait for them to fix it :)
If you need help to disable and enable it again:
How can I disable ReSharper in Visual Studio and enable it again?
with VS 2015 Enterprise i get always following message on a solution while debugging: XAML Visual Diagnostic is either disabled or is not supported by the current application
Tools - Options - Debugging - General:
Enable UI Debugging Tools for XAML is enabled
Preview selected elements in Live Visual Tree is enabled
I have tried:
VS Restart
Clean Solution / Rebuild
Fresh Checkout
Curious: If i start the solution without debugging and i attach the debugger to the process, it works ...
Update:
If i select "Enable native code debugging" in project settings - debug, it works !
I needed an additional debugging option to be disabled in order for the tools to work with my projects:
Tools - Options - Debugging - General:
Use Managed Compatibility Mode --> disabled
I also faced this problem for some WPF projects that came to my pc from various sources. In my case the problem was in the project target framework - it was set to .NET Framework 3.5. The Live Visual Tree and the Live Property Explorer in VS 2015 do not work with .NET 3.5:
Inspect XAML properties while debugging
https://msdn.microsoft.com/en-us/library/mt270227.aspx
So I just changed the target framework to .NET Framework 4.0 in the project properties dialog (the Application tab) to make these 'live' tools work.
I faced the save issue on VS 2019. It happened all of a sudden on a project which it used to work on. Restarting VS did not help. But it got resolved after PC restart.
If you're having that problem in VS 2017 while debugging on a remote machine, installing the Visual C++ 2017 Redistributable (x64 in my case) made UI debugging work.
I always had this VM where UI debugging worked but my colleagues couldn't get it to work on their machines until I was experimenting with something where I had to uninstall all redistributables. After finishing my experiments I realized I couldn't debug the UI anymore. I reinstalled the 2017 redistributable and the functionality got enabled again.
When using Visual Studio Enterprise RC to create a new .NET Framework 4.6 ASP.NET Application using the Web Site template I am receiving an object reference not set to an instance of an object error. After dismissing the error the project seems to be ok, but I would like to be sure.
Both the Empty and Web API template work fine.
I have tried creating the project with Visual Studio in safe mode as well as creating a new project with a separate instance of Visual Studio attached for debugging. None of this has given me a clue as to what the problem might be.
Any idea what could be causing this issue? Or pointers on next steps to take?
You can now upgrade to the full Visual Studio RTM version. That should fix your problems.
I would like to run a .exe file made with visual studio 2003 but I get an error every time I run it on a windows 7 machine, vista machine, and xp machine. The error on Windows 7 and vista says "application has stopped working" and then makes me close the error box.
In windows xp it's a little different error, "the application failed to operate (0xc0000135) Click on OK to terminate the application."
That error code seems to indicate the application failed to initialize correctly.
It is possible that the anticipated .NET version is not present.
As far as I know, VS 2003 by default compiles against the .NET 1.1 library. There is no straightforward way of installing this on a Windows 7 or Vista box. Do you need to compile it against the .NET 1.1 library, or can you load it in VS2005, change the output .net version to 2.0 or higher, and recompile the application?
If you have the source code to the application, try running the application in debug mode and stepping through line by line until you find the exception. If you do not have the source code, possibly try running the application in a couple different compatibility modes. Another option to try is to check the windows event log for anything more specific.
If you want to get really deep into it, you can use SysInternals ProcMon.exe and filter on the failing exe to view the WinAPI calls that are happening during the failure.
Also, a basic search of forums shows that error is usually accompanied with framework issues. Either recompile the application or check out what your required framework is in the VS2003 project settings.
i get a HRESULT 0x80131047 exception in Microsoft Visual Basic 2008 express when debug my application. this happens whenever i click "start debugging" and it doesn't matter what application i load. this is a brand new vista x64 bit machine with a fresh install of VB2008 express.
This MSDN forum post says that you need to take "special" characters such as slashes, commas, or apostrophes out of your assembly name to avoid that error.
If that doesn't fix it, another suggestion there is to uncheck "Enable the Visual Studio Hosting Process" in the Debug tab.
It may not necessarily be special character as in my case...
This was a hard issue to troubleshoot as there may be many variables leading non-functioning assemblies.
So I was working on an Outlook Add-In 2010 targeting the 32-bit version of Office. Everything was working fine until one day out of the blues, the add-in wouldn't load anymore and I was presented with error "HRESULT: 0x80131047". After searching almost half-a-day I found a nice article:
http://blogs.msdn.com/b/astebner/archive/2007/05/06/2457576.aspx
I tried adding the assembly to the global cache but was unable to. Luckily, I had an almost identical project which ran just fine and I had already done comparison checks but all references and settings were the same, but on this pass I found something different ... as it turned out the platform target CPU was set to 64-bit so I changed it to "Any" and voila'! - problem fixed!
I was then able to run the project in Debug mode, Outlook launched and loaded with Add-in without a hitch.