When I try to debug in Visual Studio I get the error message:
Unable to copy file "C:\Users\Name\Dropbox\Company Name\Development\Product Name 4 - Release Candidate\packages\MahApps.Metro.1.1.2.0\lib\net45\MahApps.Metro.dll" to "bin\Debug\MahApps.Metro.dll". The process cannot access the file 'bin\Debug\MahApps.Metro.dll' because it is being used by another process. Product Name 4 - Release Candidate
How can I fix this error?
This happens all the time in Dropbox. Dropbox does some occasional (very brief) locking of files as it is indexing them, and if you happen to attempt to open a file handle with the write attribute set at the same moment, the program will receive a file I/O exception (this can happen to your own code as well, so if you regularly work in Dropbox, be sure to handle that gracefully).
Try compiling/running it again and see if the problem goes away. If not, then you likely still have an instance of your application running in the background. This can occur if your program ever forks. VS will terminate the original process, but often not forked processes from it. Check task manager to be sure. It will be listed as a background process in Windows 8/8.1
Related
After failing to get DebugDiag to analyse crash-dump files it was suggested that I try using WinDbg instead.
The crash-dump files have been created on a Windows Server 2016 box, running my ASP.Net 4.5.2 web application on IIS-10. My ASP.Net web application contains several 3rd party components, with their individual DLLs.
I have copied the crash-dump files onto my Windows 10 development machine, and am running WinDbg locally instead of on the server.
The problem is... when I run !analyze -v in WinDbg on any of the crash-dump files, it effectively hangs while "Downloading file xxx.DLL" (xxx.DLL being the name of just one of the 3rd party component DLLs), and eventually cancels itself after a period of time.
I'm running WinDbg on the same machine that I built the website on in the first place... so is there a way of telling WinDbg that it can find the DLL in a particular location on the local machine?
I obviously don't have a .pdb file for any of the 3rd party components, and so I'm not bothered about it loading symbols for those DLLs... but either I somehow tell it to ignore those particular DLLs, or I tell it how to find them locally.
Can anybody point me in the right direction?
You don't have to analyze the dump file with !analyze -v.
If you need to load dll, then .load D:.... is enough.
To maunal analyze a dump file.
Please run .loadb sos clr to load debug module. If the crash server and your machine run different version of .net framework. Then you need to load sos.dll manually.
When you need to debug .net application in IIS, !mex extension is recommened.
https://www.microsoft.com/en-us/download/details.aspx?id=53304
You can load mex.dll via .load c:\.....\mex.dll
!mex.aspxpages can show all requests inside the process and their process
!mex.mthreads show the status of all threads
!mex.clrstack2 will show all exceptions and mananaged call stack in specific thread.
1.You can use ~* k to load the full call stack in all threads and !mex.mthreads check status.
Then you may find something like KERNELBASE!RaiseException in specific thread
2.Then go to this thread via threadid~ like 12~
3.Run !mex.clrstack2 and it will show the crash exception
Basically, no, you cannot speed up the process of loading symbols for DLLs where you don't have symbols. IMHO, the only way of speeding up the symbol process would be to disable the HTTP server, so that symbols are only searched on your local disk.
See also: How to set up symbols in WinDbg if you have not done this often.
Getting a HTTP 404 for those files should not take very long. However, it tries various file endings and pointers etc. Sometimes Microsoft servers are slow. Also, having a lot of 3rd party DLLs may sum up of course. That can be pretty anoying.
I'll start by saying I don't 100% understand everything I had to do, but here are the step I took to discover where the stackoverflow issue was in my application...
The majority of the information came from this blog.
On the server I added the following registry settings to create the crash dump files...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpCount"=dword:00000005
"DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,\
00,6d,00,70,00,73,00,5c,00,00,00
(The DumpCount is the number of files to store before it starts overwriting old ones - DumpFolder is where the files are to be saved, is a REG_EXPAND_SZ and in my case represents C:\CrashDumps\)
Waited for crashes to happen
Copied the crash files into a directory on my local machine called C:\WinDbg\CrashDumps\
Create another directory called C:\WinDbg\Symbols, into which I placed...
clr.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
sos.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
all .dll and .pdb files from my local development environment, including third party component .dll files
Installed WinDbg via Windows Store on my Windows 10 development machine
Ran windbgx -y c:\windbg\symbols via Run command (for some reason it's windbgx on my machine but maybe that's because it's via the Store rather than manual download)
In the file menu Open dump file and select one of the dump files in C:\WinDbg\CrashDumps
Ran the following commands...
.symfix
.reload
.load c:\windbg\symbols\sos.dll (see note 1 below)
!clrstack (see note 2 below)
Although this didn't give me all the information I expected, what it did show was that one of my 3rd party components was 100% to blame for the stackoverflow exception.
Note 1 - Lots of places I read said that .loadby sos clr should be used, but that just gave me The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed and I couldn't figure out how to fix it... so instead I've used .load c:\windbg\symbols\sos.dll.
Note 2 - The !clrstack command worked because WinDbg appeared to pre-select the thread that had the exception. The other option is to use ~*e !clrstack which will show you call stacks for ALL threads.
I have a webjob that I'm debugging locally as a console app. But once I stop the code from within VS2017 I'm unable to recompile the exe as I get the following error
Unable to copy file "obj\Debug\******.******.exe" to "bin\Debug\******.******.exe". Access to the path 'bin\Debug\******.******.exe' is denied.
When I look at the processes that are running theres nothing there that jumps out.
I've closed VS and restarted it, but thats not cleared the issue.
Other than restarting my machine is there anything else I can try?
You can use the Windows Resource Monitor tool. Once opened, navigate to the CPU tab and enter the full path of the .exe (e.g. C:\Project\bin\debug\App.exe) in the Search Handles text box in the bottom-mid right corner and search. You should see the list of processes currently locking on the particular resource (in this case, the .exe). Select all the unwanted processes, right-click and end process. Depending upon on the version of Windows you are running, the experience might differ a bit but the general idea is more or less the same.
When running a UWP project I'm working on I receive the following dialog.
"Unable to activate Windows Store app 'MyAppsMangledName'. The 'MyExeName' process started, but the activation request failed with error 'The App didn't start'."
The Visual Studio output has the following.
The thread 0x3d4c has exited with code -1073741515 (0xc0000135).
The thread 0x3b50 has exited with code -1073741515 (0xc0000135).
The program 'MyExeName' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
The Event Viewer has 3 events that basically restate the popup dialog in 3 different ways and nothing else.
Running Process Monitor during the startup shows me many dlls being successfully loaded but nothing indicating failure besides some NAMENOTFOUND events which unfortunately don't show what name wasn't found.
In Win32 a helpful dialog usually indicates which dll could not be loaded. And of course with .Net apps the fusion logs make tracing this very straight forward. But for Store/UWP apps I can't seem to find a good way to track down the offending dependency.
This just hit me too on a project I'm working on. And after much digging, someone on my team was able to figure it out. So figured I'd share it for others struggling with the same issue.
We're doing UWP with C++ using VS2015. So with that in mind, there is a program called gflags located for me at C:\program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
So you'll want a cmd window with admin, and run the command gflags.exe -i your-program-name.exe +sls
Note: gflags wasn't in my path so either add the path or navigate to where it is before executing the command.
Just pass in the name of the exe without directories. What it does is sets a registry setting for VS that turns on sls (show loader snaps) for exe's matching that name. Then run your application in VS and and you'll get a large amount of dll loading information including names of the dlls that fail to load in your output window. In our case it was this:
5038:34f4 # 789320468 - LdrpProcessWork - ERROR: Unable to load DLL: "vccorlib140d_app.DLL", Parent Module: "E:\projects---\Source\Builds\vs2015_Debug_UWP_x64\AppX---.exe", Status: 0xc0000135
Another quicker alternative way to test this (YMMV) was to compare the output with another build config that does work. In our case, we can run release builds just fine, but debug builds barf. And the release output showed vccorlib140_app.dll loaded while the debug had it missing.
I am trying find a problem with my program that is hooking into a game. This is
vc++. Basically I launch the program and then hook into it using SDL. When I run the code from VS2010, all works fine. But when I try to run from command prompt, my program can launch the game, but after that the game crashes immediately.
I was viewing windows event logs, and it appears that there is an access violation. 0xc000005
How can I log any further details about the program that crashes? I tried "procdump" but that is not useful as I cannot INDIRECTLY target the hooked game from console. Rather it can only target my application that hooks.
Anyway of getting detailed dumps is highly appreciated in this case.
Thanks!
You can perform postmortem debugging by using a combination of the WER registry keys/values to trap any dump that is produced. I’ve used this method to prevent the WER system from collecting the dump file (.dmp). I’ve also written about this in another similar post. To accomplish this, you will need to create a registry key under
Software\Microsoft\Windows\Windows Error Reporting
if one does not already exist. The key should be
LocalDumps\your application.exe
Once that’s done, modify these keys/values to meet your needs:
DumpCount, DumpFolder, DumpType
You’ll need Administrator rights to create and modify the keys, and, you should reset everything you’ve modified when you’re done debugging.
I've managed to get myself in a state where I've no instances of devenv running, but still a MyApp.vshost.exe in the background (no visible windows or consoles).
I've tried TaskManager, ProcessExplorer and command line (taskkill /F /IM MyApp.vshost.exe), none of them complain, the command line even says 'PID 5824 stopped', but it's still there.
I know I can reboot, but I'd rather get to the bottom of this.
It doesn't look like it's this issue (http://support.microsoft.com/kb/982551), because I can reboot no problem (just have in fact, so won't be able to provide any further diagnostics, sorry).
EDIT
This is how I got into this pickle:
I was able to kill my persistent vshost process by following these steps (VS2010):
open the properties of my executable project
in the "Debug" tab, uncheck "Enable the Visual Studio hosting process"
save the project file
That was it, the process stopped, and there was no need to restart Visual Studio.
It seems to be the normal behaviour for this task. When you kill it the task is restarted.
So i advice you to close Visual Studio, that closes the *.vshost.exe task.
I had the same problem while working on a project with .NET 2.0 as target framework.
Temporary changing the target framework to .NET 4.0 client did the job for me.
However, Iam unsure how this is (is it?) related to the file lock issue.
Maybe that's the same problem as described in https://stackoverflow.com/a/1582747/254041 (pending I/O processes):
The MSDN API ref says "TerminateProcess initiates termination and returns immediately. This stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled.". Which means so much as: your I/O can block this process (though I wonder how it can bring your process to 100%, I/O usually doesn't do that).