I am running Windows 8 with UAC completely disabled which is possible to do by changing a registry setting (setting it to "Never notify" no longer completely disables it in Windows 8).
When I try to profile C# code through Visual Studio I get the following error (clicking yes doesn't resolve the problem):
Unable to open profiler driver, would you like to upgrade credentials of [username]?
Running vsperfcmd /Admin:Driver,START from the command line says:
Error VSP1449: Unable to start VSPerfDrv100. This driver has been
blocked from loading Try using the /Admin switch of VSPerfCmd from an
elevated environment.
I obviously am using an elevated environment, since with UAC completely disabled I no longer have two security tokens but only the administrator security token.
How can I resolve this problem?
The blog post here 'The Visual Studio Profiler on Windows 8' states this:
Windows 8 added logic to prevent all incompatible versions of the
profiling driver from starting (2010, 2008, and 2005).
This means that when you try to start profiling with an incompatible
version you will receive the message “Error VSP1398: The monitor was
unable to start the VS performance driver. Access is denied. Consider
using the /Admin:Driver,Start and /Admin:Security options of VSPerfCmd
from an elevated environment.”
Which will result in the following behavior when running Visual Studio
2010 (or earlier) on Windows 8.
CPU Sampling, .NET Memory Allocation, and Concurrency profiling will fail to start on Windows 8. The only workaround on Windows 8
is to use Visual Studio 2012 Professional or higher, or to profile
on Windows 7.
Instrumentation profiling can be launched, but the application and elapsed times will be exactly the same.
Try adding "Full Controll" permissions to the directory where the driver "VSPerfDrv100.sys" is located.
You can find this using "sc qc VSPerfDrv100".
For an x64 PC it should be "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Performance Tools\x64"
Related
I've a problem on a preproduction server and I thought it was the right time to try the time travel debugger added to the WinDbg Preview.
But it seems impossible to get it outside a dev machine:
Install only available from the store ... so need to be connected on the store
Windows 10 requirements
Is this features usable outside the development environment ? If yes, how ?
Thank you
If you target OS is Windows Server 2016, 2019 or Windows 10, you can use the standalone reduced features version of TTD, now present in most recent versions of Windows. For now, the only thing you can do with this standalone version that comes with the OS is to attach to an existing process to record the trace. This is the command syntax:
Requires elevated privileges
TTTracer [-out <folder-name-for-run-file>] -attach <PID>
Example:
After reproducing the problem, run from another command prompt to stop capturing:
TTTracer -stop all
Example:
Open this website and type in the url for the Windbg Preview and click on checkmark to generate the links to the appx files.
,
now download the appx and install it with the App Installer or extract it with Unzipping Tool like 7zip and run it on older Windows like Windows 7/8.1.
I'm experimenting the following error when I run the Windows App Certification Kit on a brain new C# Universal App: "Task failed to enable HighVersionLie".
Windows 10 1709 (Build 16299.125)
Visual Studio Pro 2017 (15.5.4)
New project C# Universal App (no additional code added to the project)
Min SDK version: Windows 10 (10.0; Build 10240)
Target SDK version: Windows 10 Fall Creators Update (10.0; Build 16299)
Windows App Certification Kit: 10.0.16299.15
If I generate the appxbundle, the certification kit fails with error "Task failed to enable HighVersionLie".
If I copy this appxbundle on another Windows 10 instance with the same certification kit and pass the test again, there is no error (the HighVersionLie passed successfully)
The "HighVersionLie" test checks to see if your app will crash if it is told that it is running on a new, higher version of Windows (a version which has not been released yet).
I'm guessing that the machine you are seeing the problem on has a problem running this test, and it is not the app's problem.
If you run Visual Studio as Administrator, and then run the tests, do you still see the problem?
You might also check for a corrupt installation by running sfc /scannow from a command prompt, or reinstalling Visual Studio
Finally, you might try running Event Viewer, and checking the "Application" log to see if there are any Errors around the time you ran your certification test. If you see an error here, Google the description to find out what's wrong.
If you still think it is a problem with the app, you might check out my HighVersionLie answer here.
I am having problem getting the MS Visual Studio Remote Debugger to connect to my local IE instance as it is running as a 64-bit rather than a 32-bit process.
Every time I try to run it currently in Visual Studio I get the
The 32-bit version of the Visual Studio Remote Debugging Monitor (MSVSMON.EXE) cannot be used to debug 64-bit processes or 64-bit dumps".
error.
Investigating a bit, I think I have narrowed it down to the web asp service being run as a x64 process rather than a x86 (which both Visual Studio, and the silver light application are running as). I confirmed it as running as a 64-bit process by trying to "attach" visual studio to the process when the application was running in the ASP.Net Development Server.
In short: Is there a setting I am missing somewhere to force Visual Studio to run the ASP.Net service as a 32-bit process? I have read about using a variable in the web.config application pool to use 32-bit (via the enable32BitAppOnWin64 config option), but it seems to only work in IIS, not ASP.net Dev server.
Any thoughts?
Edit For Clarity:
I am running Windows 7 64-bit, Visual Studio 2010 (which is running as a 32-bit process). Currently it is launching ASP.NET Development Server (not IIS) to host the back end web service. I am hoping I can simply "fix" this via a setting, but if not my backup would be to run IIS Express.
If I'm understanding you correctly you should do this:
IIS Manager/Application Pools-> choose the correct pool for your application/Advanced Settings/Enable 32-Bit Applications->set it to true !
I had problem like this in the past which cost me 1-2 days, hope this helps !
Check also Project/Properties/Build/Platform target->this should be Any CPU
What is the difference between using Visual Studio 2012 "Run as Administrator" mode and otherwise? Why do developers prefer using VS in administrator mode? What are the advantages/privileges that one gets?
I may be naive enough to ask this one but I am just curious. Thanks.
From MSDN: User Permissions and Visual Studio
You can do nearly everything in the Visual Studio IDE as a normal
user, but, you need administrator permissions to complete the
following tasks:
Installing Visual Studio.
Upgrading from a trial edition of Visual Studio.
Installing, updating, or removing local Help content.
Developing solutions for SharePoint 2010.
Acquiring a developer license for Windows Store.
Adding classic COM controls to the Toolbox.
Installing and using add-ins that were written by using classic COM in the IDE.
Using post-build events that register a component.
Including a registration step when you build C++ projects.
Debugging applications that run with elevated permissions.
Debugging applications that a run under a different user account, such as ASP.NET websites.
Debugging in Zone for XAML Browser Applications (XBAP).
Using the emulator to debug cloud service projects for Windows Azure.
Configuring a firewall for remote debugging.
Profiling an application.
Deploying a web application to Internet Information Services (IIS) on a local computer.
Changing how you participate in the Visual Studio Customer Experience Program.
Windows Vista introduced User Account Control which means that you are running all programs as a standard user even if you are an admin. There are certain things that you in VS that requires you to be running as an admin, not a standard user. For example running Windows Azure emulators, asp.net dev server, etc.
You can run VS as a standard user but sooner or later you will run into issues.
Is there a way to set up Remote Debugging (Msvscom.exe) on a machine that does not have Visual Studio installed?
I would like to attach to the service running on the VM so I can debug an issue in the code. I've done this before but both machines have had VS installed.
The Dev box is running Visual Studio 2010/Windows 7. The VM is running Windows 7 without Visual Studio.
I'm going to resurrect this because anyone who's tried to do this knows it's a complete pain in the ass every time, and that it changes slightly with every possible combination of host/remote system you can have.
Visual Studio Remote Tools Links:
Visual Studio 2010 remote debugger. (Working as of 21/Oct/2016)
Visual Studio 2013 remote tools (working as of 21/Oct/2016)
Visual Studio 2015 remote tools x86 - Direct download link
Visual Studio 2015 remote tools x64 - Direct download link
Visual Studio Tools (Thanks Robo Burned)
Visual Studio 2017 Remote Tools x64 - Direct download link (Thanks Isaac Baker)
Visual Studio 2017 Remote Tools x86 - Direct download link (Thanks Isaac Baker)
Visual Studio 2019 Remote Tools - download link
This is the setup I succeeded with today:
Host (Dev) Machine:
Windows 7 Ultimate SP1 x64. Running Visual Studio 2010, .NET Framework 4.
Remote Machine:
Industrial/Factory Floor PC running Windows Embedded Standard 32-bit. It looks/feels exactly like Windows 7. Running SP1. Visual Studio is not installed. Has the .NET framework 4.
Network:
Both machines are on the same subnet. I access the remote machine via RDP and run my application that way.
Microsoft-Proprietary Follicle-Deterioration Implementation:
Make note of your dev machine's user name and password. For some reason you have to create exactly the same user name and password on the remote machine. Because Microsoft.
How I did it:
I downloaded the Visual Studio 2010 remote debugger from the link provided by #sJhonny. I had to switch off of Visual Studio 2013 in that article and over to 2010. If you care to go over the 2010 article with a fine-tooth comb to find the download, the link is right next to the "No one ever finds this helpful" link at the top. If not, just follow my link above.
Install that on the remote machine and run the configuration wizard. I left the defaults for the wizard:
"Run the 'Visual Studio ....." was checked off
Username is LocalSystem and password is blank
Allow only computers on the local network....
Run the Remote Debugger on the remote system and you'll see
Msvsmon started a new server named 'username#machinename...'
in the interface. So far so good. Run the application on the remote machine. On the dev machine, Ctrl+Alt+P in visual studio will open "Attach to Process" (It's also under the tools menu). I got a popup about my dev machine's firewall not being configured properly and was asked if I wanted to allow the connections etc... Say yes obviously.
Enter the 'username#machinename' combination into the qualifier box... press Refresh and pray a little. Pray a little more a lot harder and you should see a list of the processes running on the remote machine. Select your process and attach to it.
But my breakpoints don't work!? Of course they don't... because using the breakpoints in the same directory as the application on the remote machine would make too much sense. If you were lucky enough, you got warned about a breakpoint cache and got shown a dialog with a path.
The dialog mentions something about it being correct relative to the remote machine. It's lying. It has nothing to do with the remote machine except that it forced you to create a brand new user over there with the same name as your current user because Microsoft. To get your breakpoints to work, follow the path on your dev machine (customizable in Tools>Options>Debugging>Symbols: Cache symbols in this directory) and copy your application's .pdb files over to that directory. You have to copy them over with every new build, unless there's an option to do it automatically; I haven't checked because I have yet to stop celebrating my remote debugging success.
Everything should work now.
certainly there is.
You can install msvsmon without installing visual studio.
I've done this myself on several machines.
the tricky part lays in authorization- the user running VS on your local machine needs special priviliges on the remote machine.
ms has some articles explaining the details- http://msdn.microsoft.com/en-us/library/bt727f1t.aspx,
Update:
Here's the links for 2017 which are not obvious to find either.
Visual Studio Remote Tools Links x64 direct link
Visual Studio Remote Tools Links x86 direct link
Taken from:
how-to-implement-remote-debugging-in-visual-studio-2005
Let's consider an example to understand this situation clearly. Molly
Clark and Adam Barr are both employees at Adventure Works. Adventure
Works has a Microsoft Windows NT domain named adventure-works.com.
Adam is having trouble with some software that Molly wrote. Molly
would like to debug this software on Adam's computer. Molly and Adam
follow these steps:
Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program
Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory
on her computer. She creates a file share called Remote.
Adam runs \MollyComputerName\Remote\x86\Msvsmon.exe.
After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions
dialog box. He gives Molly permission to debug.
Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.
Molly starts Visual Studio 2005.
To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
Molly connects to Adam's computer by entering adventure-works.com\Adam#AdamComputerName in the Qualifier box.
Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in
the application.
There's also another way which I prefer (if you have fast internet connection).
You don't have to download or install anything on remote desktop connection.
You can share your disk C: while connecting via Remote Desktop Connection.
On the remote desktop go to location (depending on your local location)
\\tsclient\C\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Remote Debugger\x64
(optional) Create shortcut to folder or msvsmon.exe on desktop
Run it remotely from your local disk via shared disk. (start can take few seconds depending on your connection quality)
Option2: Copy Remote Debugger\x64 or x86 folder to the remote location and use it.
I was able to get it working with asp.net core 2.1, the only difference from the answers above was that the process you attach to is dotnet.exe.