"The application could not be launched for debugging. Please make sure the device is unlocked."
I am getting this error when I try to launch the app on my device for debugging.
I have tried the following:
Relaunch Visual Studio,
Reinstall Visual Studio,
Restart my computer,
I have selected both debug and release in the configuration window.
The problem is that its not getting launched even in the emulator. The emulator opens and never loads the app but gives the same error message. And I have tried to just open a new application on VS and tried to run the default application. That also gives the same problem.
Everything was working fine after I opened a few more projects for reference, It suddenly started giving this error message.
Make sure a Windows project is not set as startup(assuming you have both windoes project and phone project in the same solution). For example If your target platfrom is a Windows phone project WP7, then you cannot have a windows project as startup. This is a known reason for the error you mentioned.
Also what is the operating system you are working with? I know the error you mentioned reprorted on some OS's including Windows server 2003 and 2008. Try running your project in winsdows 7.
I suddenly got exactly the same issue today. I was coding like always and then I got this problem.
// P.S.
// Today I updated Windows from 8 to 8.1
// Then I installed VS 2013 preview
// But continued working in VS 2012 (I need R#)
// After ~ 5 hours of work I got this issue
I tried everything, deleted emulators from Hyper-V, deleted all virtual commutators, restarted VS 2012, restarted laptop, deleted Bin and obj folders from project, rebuilded project.
But nothing helped.
Then I tried to open solution in VS 2013 preview, and it works!!
I hope I help you with this answer.
If somebody know how to fix it in VS 2012, please tell us
I have a similar problem but I’m able to debug my app once I click OK on the error prompt following the “Launching TaskHost.exe failed.” message in the status bar. I haven’t been able to solve it but I’ve found a workaround that might also work for you.
Start the “Simulation Dashboard” under “Tools” and instead of starting the debugger the usual way build your project if needed and then try to start the debugger by clicking “Locked” under “Lock Screen” on the dashboard.
This answer worked for me.
Under the following:
Solution(Right-click) > Properties > Configuration Properties > Configuration
Ensure that your main project is set to 'Deploy.'
Related
Update: this bug has been fixed for a while now
I installed Visual Studio 2017.3 yesterday and was trying to used the new Development time IIS Support feature. I think I encountered a bug, and I was wondering if anyone knows a workaround this bug. When I used it with a new project it works fine most of the time. By most of the time, is that I think it is broken sometimes depending on the where the project is located/state of cached data, etc.
Sometimes I get an error "Value cannot be null. Parameter name: name". That's the entire error. No log files, no extra information.
I tried to enable the feature for an existing project I am working
on, it got that error.
I tried adding a new web project in a new solution it worked fine. I tried adding a new web project in the same solution as my project, it didn't work.
I deleted all temp files, all bin obj and .vs folders and .user files in the
solution. Same problem.
I deleted temp folder, visual studio user profile data, and restarted the PC same problem.
I tried again in the same solution with the project not having '.' in the name, it worked.
I did some modification to the project that was working and tried to launch again I got same error.
I reverted all changes so that the project was back to the "empty project" state, still same error.
I removed the project. Exited visual studio, deleted all temp/.vs/.use/bin/obj files. Then restarted and added the project again, it worked.
I restarted VS and tried to relaunch it didn't work.
The aspnet core version seems to be not related to the bug. I had the problem with projects targeting 1.1 and 2.0 and also had the feature working for both versions.
So obviously this is a bug in VS2017.3. Since even if I am doing something wrong I should at least get an error explaining what I do wrong not an ArgumentNullException message. I already made a bug report. I am wondering if someone knows a workaround thing bug.
Thanks a lot in advance.
Update: This bug has been fixed for a while now.
After some investigation and with help from a helpful member of Microsoft's Visual Studio Team, I found that Visual Studio was failing at the point where it grants folder read access to the IIS App Pool account. The method that gets the App Pool account name was returning null, and when that null value was passed to the System.Security.Principal.NTAccount class constructor, the ArgumentNullException is thrown.
A workaround that fixed the problem for me, was changing the App Pool to any other App Pool, trying to launch, then changing it back to the original/desired App Pool.
First You Must Update Visual studio with visual studio Installer and Launch the Visual Studio installer.
And Select the Development time IIS support component and Modify.
Wait For Download is Processing
The component is listed as optional in the Summary panel for the ASP.NET and web development workload.
Then you Create New Project Again
Problem Solved.
I am developing an iPad application with Xamarin.iOS and MVVMcross. So I have a PCL with my View-Model and my Model, and an iOS project with the view. I use Visual Studio.
Before, I used Xamarin.iOS 6.3.6 beta version, and when I tried to launch the app on the device, an .app file was created and getting it with my Ipad, I could launch the application (impossible to launch directly from Visual Studio).
Yesterday, I uploaded Xamarin.iOS to 6.4.1. On simulator, everything's okay. When I try to launch the application on device, now the app is directly installed but the build stop and the following error appear in the debug output :
Failed to load AOT module '<my PCL>' while running in aot-only mode: doesn't match assembly.
And if I click on my app icon on the device,a black screen appear and disappear immediately.
Does someone know why this error appear?
This looks like something was cached somewhere or not updated correctly.
Here are a few ideas to try:
Delete the app from the device.
Clean & Rebuild your app.
Build & install from Xamarin Studio on your Mac.
Copy the Debug configuration to a new configuration (DebugTest for instance), and run that configuration instead.
I regularly get the same issue here.
The workaround that I use is to switch the platform in the Visual Studio build Configuration Manager to "iPhoneSimulator", run a quick debug session on that, then switch the platform back to "iPhone", and the problem disappears for a while.
Unfortunately I have no intelligent reason as to why this works. It seems to be doing a better job of the "Clean and Rebuild".
After reading a similar bug, I found that clearing the mtbs folder on the OS X host which is located at $HOME/Library/Caches/Xamarin/mtbs/ fixes this problem for me.
I have to do it so frequently I just have a PuTTY session open on my Windows box to clear the folder. I do hope that Xamarin fixes this issue soon.
Make sure Linker Behaviour is set to Don't Link
Clean, rebuild, remove old version from app.
Worked for me at least.
This happened to me after I upgraded to XCode 5/iOS7. I noticed a warning that I hadn't installed XCode Command Line Tools. After I did that I rebuilt the application and it now runs.
I just had this problem and got it to work again by opening the Apple project properties and changing the provisioning profile identity from "Distribution" to "Developer".
My workaround on Mac is to
Close Solution in XS
Quit XS. Command-Q
Reopen it and reopen solution.
After that it usually works again.
Everything had beed working great, but suddenly something happened and every time I try to open any web-based project (either MVC or just 'Open Web Site', any others are just fine), Visual Studio 2012 crashes with Windows environment message:
MyProject - Microsoft Visual Studio (Administrator): devenv.exe - System error
Exception Processing Message 0xc0000005 Parameters 0x000007FEFD4A718C 0x000007FEFD4A718C 0x000007FEFD4A718C 0x000007FEFD4A718C
ОК
I did not notice exact moment when it stopped working. And obviously I have different extensions etc. But I believe, I did not install any big soft these days.
I've installed Windows 8 though, but separatly - on separate volume to try it. Theoretically, it might affect my situation, but I don't know how is that possible - at least I don't know any explanations.
I've tried to refresh Visual Studio 2012 installation, even removed and installed it again.
However, at the same time, I have Visual Studio 2010 previously installed, and it opens web-based projects without any problems.
Mentioned error message above is, as I understand, some generic error message - googling did not help on its recognizing, so don't know what to do - don't really want to reinstall Windows because of that.
Does anyone have any thoughts? Thanks!
I really don't know what was the cause of the problem, but after all other tries I've applied all pending updates of Windows Update service and everything works well after that.
I am getting the following error when starting Visual Studio 2012 as unprivileged user:
An error has occurred while trying to access the log file. Logging may not function properly.
A casual web search showed that the issue used to exist with VMware 6 beta, back in 2006. I also found one other user who experiences the same in a more recent VS version (2008) and it started only recently.
The title of the message box indicates that this comes from VMware. I have VMware 9 Workstation installed. The problem could be related to system updates or the update 2012.2 CTP and hasn't gone with the final 2012.2 update package.
The question:
How can I get rid of the error without actually disabling the VMDebugger add-in?
Temporary workaround:
There is a workaround, disabling VMDebugger in the "Add-in Manager". However, it even seems that unprivileged users are unable to successfully disable it. I had to start VS as admin (I am using SuRun for the purpose) to disable it and the error not reappearing upon next start of the IDE.
I had the exact same problem, this is how I solved it.
I monitored devenv.exe using procmon to find the log path, on my computer it was: %TEMP%\vmware-username
I checked the permissions on the log directory, and discovered that my user had no access - neither read nor write! I gave myself full access and deleted the old log files. That solved it for me.
I think this happened because UAC was disabled when I installed VS and VMware.
In Visual Studio, go to the menubar to VMWARE / About VMWare Virtual Debugger; the Debugger log file will be listed there, e.g. C:\Users\Phil\AppData\Local\Temp\vmware-Phil\vmware-vsid-1.log
Give your user full access to that file.
(This solution was for Visual Studio 2013, VMware Workstation 11.1.2, Windows 8.1.)
The fastest and easiest way to solve is...
1. Locate the folder %temp%\vmware-{username}
2. Delete this folder. The folder will be created by opening the Visual Studio.
Note: You need to open the Visual Studio without admin rights to resolve the issue!
Background: Mostly this happens if you use the VMware debugger plugin the first time under admin rights (because your app may need this right to run properly). This creates the folder under admin rights with the admin permissions. Everytime you open the Visual Studio with admin rights, you have no problems.
Examples
Windows: C:\Documents and Settings\<username>\Local Settings\Temp\vmware-<username>-<PID>.log
Linux: /tmp/vmware-<username>/ui-<PID>.log
This post helped me
The fastest and easiest way to solve is...
1. Locate the folder %temp%\vmware-{username}
Go in windows+R %temp% , delete all , ready !
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.