I'm facing an issue with my visual studio 2013 (ultimate & expression).
Since 2 weeks I can't build any project without having a just in time debugger popup.
It says "An unhandled Mictosoft .Net Framework exception occured in MyApp.exe [5892]"
If I open a new visual studio to debug this issue it says ;
An unhandled exception of type 'System.Exception' occurred in App6.exe
Additional information: Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
at
static void Main(string[] args)
{
global::Windows.UI.Xaml.Application.Start((p) => new App());
}
And the output is
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'. Cannot find or open the PDB file.
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\users\david\documents\visual studio 2013\Projects\App6\App6\bin\Debug\AppX\App6.exe'. Symbols loaded.
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Runtime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.dll'. Module was built without symbols.
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\WINDOWS\system32\WinMetadata\Windows.UI.Xaml.winmd'. Module was built without symbols.
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.InteropServices.WindowsRuntime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.InteropServices.WindowsRuntime.dll'. Module was built without symbols.
'App6.exe' (CLR v4.0.30319: App6.exe): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\12.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'.
The program '[5732] App6.exe' has exited with code 0 (0x0).
I have no clue how to fix it.
I tried to uninstall and reinstall .net framework, (4.5.1 sdk + 4.5 sdk + multi targeting pack).
I tried to install visual studio 2013 express
PS: it does not occurs with visual studio 2012. Also, this exception is thrown but the application is working fine after that.
Google: 0x80040154 explains quite clearly that either MyApp.exe or App6.exe (they are both your) needs some COM object and the COM object is not registered.
As first hint try Google: "c# comvisible attribute" as it is quite possible that in some of your projects you have set it to "true"...
It is your application and you know (should know) which COM objects your application needs, so check their registration in registry.
"regsvr32" and "UAC" are related magic Google words for troubleshooting the installation process.
Windows Sysinternals Process Monitor can show you quite clearly where exactly does your application search for the registration records as all registry reads will be captured.
In order to diagnose the problem little bit further I'd recommend you to configure Visual Studio so that you can catch and see exceptions occuring inside the .NET framework code and see and read the .NET framework code shown in the call stack.
This http://msdn.microsoft.com/en-us/library/vstudio/cc667410(v=vs.120).aspx article should be enough.
And then use the Visual Studio debugger and your common sense. Whenever you see a word/term you don't know, learn what it means and continue.
With the amount of information you have provided it is not possible to guess/suggest something better.
I can try better if you provide some more information. After all your question is worth 100 rep points
Related
I am trying to debug some issues occurring within an external library (ClosedXML). If I can work out exactly what's going wrong, I should be able to apply workarounds to the code that calls it.
I have added ClosedXML and manage it via NuGet.
Unfortunately, the debugger states that ClosedXML.PDB cannot be loaded. The checkboxes for 'Microsoft Symbol Servers' and 'NuGet.org Symbol Server' are both checked.
A suggestion was to generate my own pdb file. So, I cloned the ClosedXML repo, checked out the 0.95.4 commit (the version of the NuGet package I'm using) and built the project in Debug mode. I then directly referenced the pdbs produced in the ClosedXML binaries folder in the 'No Symbols Loaded' page in Visual Studio. Unfortunately, none of them work. They each have the same error message:
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net46\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net40\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\netstandard2.0\ClosedXML.pdb: PDB does not match image.
This isn't surprising as the DLL and the PDB weren't built on the same machine, but it is unfortunate.
So, my current workaround is to dereference the NuGet package and instead reference the DLL I've built locally. This works, but it is far from ideal.
To confirm, 'Just My Code' is disabled.
Is there any way I can debug the external code without resorting to changing references each time?
You can use my Runtime Flow tool to investigate called methods and parameters in ClosedXML without .pdb.
I am investigating a crashing program but cannot load symbols for native image DLLs in Visual Studio 2013. The application is 32-bit and uses .NET 4.0.30319. I confirmed this by checking what version of clr.dll is loaded into process from the modules window. Also from the modules window, I checked where mscorlib.ni.dll was loaded from:
clr.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
mscorlib.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\ce5f61c5754789df97be8dc991c47d07\mscorlib.ni.dll
I was able to successfully generate the PDB for mscorlib.ni.dll:
but when I try to load it into VS 2013 by right clicking on the stack frame for mscorlib.ni.dll and selecting Load Symbols, I get a messaged that says "A matching symbol file was not found in this folder."
I have looked through:
Creating Ngen Pdbs for Profiling Reports/
And followed the simple instructions for generating the PDB because I just want to see function calls at this point,
Get the right .net native symols for Windbg
How to get the PDB file for mscorlib.ni.lib (.Net Framework 3.5)
It looks like the most common source of error is choosing the correct bitness. I know from the modules tab that I am loading the 32-bit variant of mscorlib.ni.dll and again from my screenshot, you can see that I am using the same version of the the .NET framework and the 32-bit version of Ngen.exe. I tried this for WindowsBase.ni.dll and saw the same behavior where I was successfully able to generate the PDB but could not load it.
I have the debugger enabled to Just-in-time debug Managed and Native code.
Questions:
Am I using the wrong version of ngen.exe on to create this PDB?
What does Visual Studio check when it tries to load a PDB?
Is there some other setting I need to enable in VS to debug this type of code?
Thanks!
I'm trying to get remote debugging working to an AOS. But my breakpoints never get hit due to symbols not being loaded.
'Ax32Serv.exe' (CLR v4.0.30319: X++ IL App Domain): Loaded 'D:\Program
Files\Microsoft Dynamics
AX\60\Server\MyAOS\Bin\XppIL\Dynamics.Ax.Application.dll423.netmodule'.
Cannot find or open the PDB file.
I have my debugging symbols setup to:
\server\d$\Program Files\Microsoft Dynamics
AX\60\Server\MyAOS\bin\XppIL
But visual studio never loads the symbols into the cache.
I'm running Visual studio as Administrator
My client configuration settings are linked to the correct AOS
I'm connecting to the AOS with the AOS-account
I'm local administrator on the AOS server
Debugging options are checked on the server configuration
Any idea what I'm missing or not doing correctly?
Procmon is telling me that the devenv.exe process can't access below path (PATH_NOT_FOUND). But I'm clueless on why it's trying to access this path.
\server\d$\Program Files\Microsoft Dynamics
AX\60\Server\MyAOS\bin\XppIL\Dynamics.Ax.Application.dll33.pdb\63A38861AB9B4E6EA55578A367A991AD1\Dynamics.Ax.Application.dll33.pdb
According to my experience deployment of assemblies hinders a proper use of Remote Debugger at AOS side.
The following steps didn't help in my circumstances:
VS symbol cache set to a local path with PDB files (VS at a remote box caches a project from AOT).
VS symbol cache set to a shared folder (AOS PDB files are exposed to a network).
Attempts to find proper order of AOS restart / clean debug information in order to sync versions of loaded DLL and loaded PDB.
AOS option "Assembly hot-swap" didn't help either. It works, however PDB and DLL are not in sync.
Tinkering with DL3 / VSAssemblies AOS folders didn't reveal any workarounds.
Eventually it was found a possible way to overcome "Missing symbol information" message which is a root cause here in my opinion. There were a couple VS projects residing at AOT which were subject for remote debugging. Every attempt showed no luck due to the same "Missing symbol information" error.
I hope the following scenario could help OP to find a solution for AIF web service:
Append CSPROJ manifest with the following lines:
<VSProjectOutputFiles Include="$(OutputPath)$(AssemblyName).pdb">
<Visible>true</Visible>
</VSProjectOutputFiles>
This helps to save PDB artifacts into AOT tree.
Compile VS project at MorphX IDE. Compilation of project at AOT is essential here, as it deploys matching PDB alongside DLL.
Restart AOS. Hot-swap didn't worked for PDB, so restart is mandatory here. As a result you can see proper PDB within "Modules" window at VS and breakpoints are reachable now thanks to that fact.
Although using Remote debugger looks truly appropriate for AOS (not to bloat server with dev tools), it seems there are still some kinks in relation to AOS code deployment.
I'm trying to debug some of the examples provided in the Maya API SDK.
Building the DLL with Visual Studio 2010 in debug mode worked fine, and the plugin, once loaded into Maya, worked fine.
However after attaching, Visual Studio complains about cannot find or open the PDB file.
I ignored those warning and set some break points, but clearly VS does not break.
Regarding building plugins and debugging by attaching them to Maya, I've read:
https://alliance.seas.upenn.edu/~cis660/wiki/index.php?title=Debug_CPP_Plugin
http://devmaster.net/forums/topic/6965-how-to-debug-a-plugin/
http://www.creativecrash.com/forums/api/topics/help-33-how-do-i-debug-my-plugin
On SE, I have read the following suggestions:
Why is Visual Studio 2010 not able to find/open PDB files?
PDB does not match image Error
Visual Studio 2010 "Cannot find or open the PDB file"
In particular, I tried:
making sure that the plugin that I am loading into Maya is the one that I just built;
verifying that the PDB has the same name, is in the same folder, has been created at
the same time than the DLL;
loading manually the PDB ("A matching symbol was not found");
activating the Symbol Server in VS (fine, but I got only the Microsoft ones obviously)
Usually, putting the pdb in the same folder will always work - however, the times where this doesn't is usually because your dll is being loaded from elsewhere in the path and its not actually running the dll you think it is (at least, that's what happens to me).
Once your app is running, try and delete the dll - if you can, its not loaded. Or you can look at the path in the modules window in VS. That will also give a clue to why its not loaded and give you the option to manually load symbols from anywhere on disk.
I am using one of the DLL file which is provided by Lync Client 2013 SDK (Microsoft.Lync.Model.dll -- version 15.0.4454.1509) in C++ code (with /CLR support). But during building the project it is not giving me any errors relevant to the code of Lync SDK class. But at run-time it is throwing me an error message:
(An unhandled exception of type 'System.IO.FileNotFoundException' occurred in scanuser.exe Additional information: Could not load file or assembly 'Microsoft.Lync.Model, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.)
//DLL I want to use
#using <Microsoft.Lync.Model.dll>
//namespace provided that DLL
using namespace Microsoft::Lync::Model;
//Function which is using that DLL
void getusername()
{
LyncClient ^lyncClient;
String ^text=lyncClient->Self->Contact->GetContactInformation(ContactInformationType::DisplayName)->ToString();
Console::WriteLine(text);
}
I also added "Additional #using Directories" in which that DLL file is present that is:
"C:\Program Files\Microsoft Office\Office15\LyncSDK\Assemblies\Desktop"
This DLL is working fine in sample applications which is written in C#. So I guess there is no problem with the sub-version of DLL
Visual Studio 2012 Ultimate,Windows 7 Ultimate 32 bit,Lync Client SDK 2013
So any ideas what's going on?