Whenever I open a Visual Studio project 2010 or 2012 I get
Microsoft Resource File To COFF Object Conversion Utility has stopped working
What I tried so far
System File Checker tool (SFC.exe) sfc /scannow I get no errors
Removed any files from %temp%
Googled and everybody suggests the above and many posts says that they could not get rid of it.
Reinstalling vs2010 and vs2012 didn't help.
Try to set Project Settings->Linker->General->Enable Incremental Linking->No.
Related
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
I'm working on a vs 2013 C# Extension project. Using Windows & and .NET 4.5 The vsix extension, when installed, works fine. However, something happened a while back, just after adding some changes, and I can no longer start the extension in the debugger. Selecting the extension project in visual studio and then selecting debug->start new instance causes VS to run through its compilation step and then launch a new version of vs with the extension in place. However, shortly after the VS black splash rectangle appears a pop up appears giving the message "The operation could not be completed-no such interface supported". The debugger has launched and is showing the modules being loaded in the "Progress Window". The last module loaded is ENVDTE80.
Running devenv with /log and copying the log file while the "Operation could not..." message is being displayed shows the last entry to be
<entry> <record>1294</record> <time>2016/02/09 16:53:22.122</time> <type>Information</type> <source>VisualStudio</source> <description>Leaving function VBDispatch::GetTypeLib</description> <guid>{80CC9F66-E7D8-4DDD-85B6-D9E6CD0E93E2}</guid>
</entry> </activity>
The guid cited appears many times throughout the activity.log.
I've looked at the odd little error messages from the devenv /LOG log. I've uninstalled the VSIX app from visual studio and then tried debugging > but no joy there. I've uninstalled visual studio and reinstalled. I've repaired the .NET installs. I've repaired the SDK. Nothing has worked. There are a few other earlier and simpler versions of the extension and test versions that debug fine. I'm inclined to think there's some bit of registry entry somewhere that finds a reason not to run this code.
From the devenv activity log I see these error messages:
<description>PkgDef configuration error. ApplicationExtensionsFolder omitted from PkgDefSearchPath</description>
The clients rights token could not be found at ....
Extension will not be loaded because an extension with the same ID 'Microsoft.Windows.DevelopmentKit.Desktop' is already loaded at > C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGER\EXTENSIONS\MICROSOFT\WINDOWS KITS\8.0\DESKTOP SDK\...</description>
I also have run procmon and captured the events between debug->start separate instance and the presentation of the error message. Two pids are > traced: one for the original devenv and one for the extension being debugged. All registry transactions for the debugged extension fall into: SUCCESS, NAME NOT FOUND, NO MORE NAMES FOUND, or BUFFER OVERFLOW. There is no distinct (to me) single error condition.
The pid associated with the launching devenv, after the last pid entry for the extension being debugged, has several entries ACCESS DENIED associated with HKLM\SOFTWARE\Microsoft\SQMClient\Windows\CommonDatapoints.
Comparing the devenv.log to the procmon, it is obvious that processing continues after the last entry in the devenv.log for ENVDTE80. I don't > seem to be getting anywhere with that correlation.
I've googled this a lot.
The common suggestion for re-registering dlls has not proven to be useful here (yet) (although it seems to have fixed an IE problem which makes it seem to be an attractive approach).
Have also un/re-installed .Net 3.5(.1) with no effect. Have run sfc /scannow with no effect. Have run NetFxRepairTool with no effect. Have rebuilt the VS extensions experimental hive (12.0-Exp) with no effect. Have un/re-installed vs2013 and the SDK with no effect Have uninstalled other versions of VS and paired SDKs to no effect
I got a little more time to look at this. I uninstalled vs sdk and vs 2013 pro and rebooted. In reinstalled 2013 pro and vs. I downloaded the dotnetframework analysis tool are ran it. I repaired dot net 4.5.1. Analysis then said to repair dot net 4.6.1 which I did. Rebooted again. Tried to run the vs extension in debug and got a different error related to the Ext hive lock file. This was an improvement from the unknown interface message previously. Ran the debug again with the devenv log file enabled. The lock file referenced in the devenv log had a "%&00A%&00D"notation in between the path ending in the /Exp directory name and the /....lock filename. Edited the profile to remove cr/lf from the end of the /RootSuffix Exp entry and thereafter debug worked.
As I start visual studio 13 it raises unknown error by saying "Microsoft Visual Studio 2014 has stop working" without any further explanation.
Here's what I've tried to solve this problem;
I reinstall .Net framework
I repair, uninstall-install Visual Studio
2013
I installed another version of VS13
but still the problem persists. Do you have any further suggestion ?
I am using Windows 8.
I've run into a similar situation described here. Once i find a solution, i will post it there.
As a first attempt i would try to generate a logfile via the /log option and see if there is a problematic extension that you could disable/deinstall, e.g. NuGet.
You say you reinstalled VS2013, so the problem might be related to settings. If reverting all settings is an option for you, see this thread on how to truly really reset your settings. This involves calling your devenv.exe with special parameters (e.g. in a cmd.exe), removing files and tinkering with the registry.
I have found the solution to this or a similar problem if you are starting Visual Studio by loading a solution file.
The symptoms are that a solution that previously could be loaded with no problems, suddenly starts having the unknown error box appear for every project in the solution. Sometimes you can't see the relationship to the continuous reappearance of the error message and the project loading, because you don't have the solution explorer open, so you aren't even aware there is a correlation.
The solution to this is to use task manager to stop visual studio, confirm with visual studio that you wish to shut it down and then look for the .suo file for the solution you are trying to load. In VS2012 it appears in the same directory as the solution file and has the extension solutionname.v11.suo while in VS2015 it appears in a hidden .vs directory under the location where the solution file is found, in a folder named for the solution.
Delete this file and the problem will go away.
The .suo file contains the user preferences for the solution you are trying to load and it is perfectly safe to delete it as it is regenerated when you load the solution.
If you are getting the unknown error when you haven't tried to load any solutions, this is probably not the right answer.
I'm building a project in Visual Studio 2010 and the build fails because it cannot copy the assemblyname.dll file from obj to bin folder. The exact error message is:
Error 7
Unable to copy file "obj\Debug\AssemblyName.dll" to "bin\AssemblyName.dll". The requested operation cannot be performed on a file with a user-mapped section open.
I think this is because the previous file in bin-folder is not accessible. When I try to delete the file manually, I get an error "The action can't be completed because the file is open in another program". If I try to see what application locks the file with Unlocker, I don't get any results (No Locking handle found).
If I restart Visual Studio, the error goes away but happens again after a build or two. Goes without saying that this is seriously slowing me down. Any advice how to start solving this?
VIsual Studio 2012 on Windows 8. I was receiving the same error message on my project. Restarting Visual Studio or cleaning the obj folder manually did not help. Finally I closed all open files (Windows -> Close All Documents) and the problem went away.
This behavior was due to a newly installed Visual Studio extension called Visual Studio Achievements (http://visualstudiogallery.msdn.microsoft.com/bc7a433b-b594-48d4-bba2-a2f24774d02f)
I noticed that the .pdb file was locked by FxCop (using Unlocker) and I think that the Achievements -extension uses it. After disabling the extension I've no longer got the error mentioned above.
This bug has been fixed in recent versions of the extension (>1.7). It was released as a beta, btw...
This behavior of VS happen very often even on my computer (and on computers of my coworkers).
In my experience it happen more frequently when:
I have some form opened in design when i compile
I stop the execution od the application by pressing the "stop" button
in VS instead of exiting the application
So, closing the form in design before compile, and exiting the application instead of stopping it, somewhat mitigate the issue... but it still happen :-|
My computer is Win 7 x64 SP1 with VS 2010 SP1, 8Gb ram, and no swap file
Platform: Windows 8 Pro, Visual Studio 2012
I found that I receive this error when I am accessing the folder in Windows Explorer.
I was creating PDF documents with Visual Studio 2012. To review the sample document I would right click in Solution Explorer and use Open Folder in File Explorer.
On Windows 7 I would get a SYSTEM.IO error if the actual PDF document was open in Adobe Reader which is expected. With Windows 8 I found that I receive the above error if I have the folder open. I suspect there is a conflict with the Windows 8 preview.
If I close the folder and run the program it works fine.
Check if you open the dll in visual studio.
I open the dll in visual studio and this error happen!!
I reinstalled Visual Studio pro 2010 due to an error.
I loaded VS and I now get this error:
The Visual Studio HTM Editor Package did not load correctly.
The problem may have been caused by a configuration change or by the installation of anothe extension.
You can get more information by running the application together with the /log parameter on the command line, and then examining
the file c:\users\lee\appdata\roaming\microsoft\visualstudio\10.0\activitylog.xml
Any ideas where to go from here.
I solved this problem by doing following steps,I am using VS Express 2012 and got the same error as mentioned above.
1)Delete(Always do remember to Backup your data) the AppData file from following location(Delete 10.0/11.0 whatever your version of VS)
a)if VS 10
C:\Users\"UserName"\AppData\Local\Microsoft\VisualStudio\10.0
b)if VS Express
C:\Users\"UserName"\AppData\Local\Microsoft\VSWinExpress\11.0
2)Update VS version from this site
MSDN Site
or directly from MSDN siteThis
3)Restart VS and enjoy
A full uninstall of Anything Visual Studio 2010/Express related, followed by a reinstall, it worked.