I am not able to debug any of my services after migrating from XP and VS2005, to Win7 and VS2010.
I can compile, I can install, I can run the services correctly.
But, I need to debug them. And when I try to attach to the process, I select the running process as I always did on VS2005, and I receive an error telling that I need admin permission.
I am already an administrator. Also, after searching a lot on the internet, I found that running VS2010 as an admin (via right click) should fix it, but I still can't.
I also tried to mark the checkbox on vslauncher.exe properties to run it always as administrator. The VS2010 window shows on top that it actually is running as admin, but again, when I try to attach to the process it says that I need admin rights.
Has anybody any idea about how to proceed?
It was a permissions problem.
Win7 comes with a new security system, and I had to add to my profile (even being an admin) this permission:
Control panel -> Administrative tools -> Local Security policy -> Local Policies -> User rights Assignment -> Debug programs -> Add user or group .
And there, I added my own user. Reboot machine(Important!! Without rebooting, it won't work).
After that, I was able to attach processes to debug them. It's been a really long time to solve this, I hope to help other people that find this same problem.
Thanks everybody for your help.
Edit your service and put the following line into the OnStart() method:
Debugger.Launch(); It's important that you do this in OnStart() rather than a thread launched by OnStart() so that if there is any bug, you can catch it prior to your service crashing.
When your service starts the debugger will open. Windows will then offer to automatically launch an elevated visual studio so you can attach to your service. I find it very useful to put this line in with an app.config setting so you can enable it as required (i.e launch and attach debugger to service).
FYI when you use Vista / Windows 7 you can run apps as administrator. However these apps explicitly reject administrative privileges unless you launch them with "Elevated" permissions. This is a security feature called UAC.
Related
I am building an auto-updating mechanism. A windows service that runs on a local service account responsible with the auto-updating of a msi.
The service downloads the msi file then it tries to install it using this code:
Process process = new Process();
process.StartInfo.FileName = "msiexec.exe";
process.StartInfo.Arguments = string.Format(" /i \"{0}\" /qn /norestart ALLUSERS=1", sMSIPath);
process.Start();
process.WaitForExit();
Where sMSIPath is a string representing the path to the file, for example "C:\test.msi".
This code, from a regular console application seems to be running fine. I managed to silently install adobe reader, for example.
But from my windows service, it does nothing. According to the logs, i get a warning with this message:
Failed to connect to server. Error: 0x80070005
Where the user is "LOCAL SERVICE" (as i mentioned, my windows service runs as a local service).
Also, the projects have target x86, but i am running a 64-bit OS. (i need them at x86, i want this software to be able to run on multiple operating systems).
Any help is very well received.
Thanks alot!
I don't think you have much chance of making this work. If the MSI tries to access folders like Desktop, User's Program Menu, the CommonFilesFolder (not a complete list) or looks at the LogonUser property and any number of other things it will fail because in a normal install from the interactive user these are all valid properties associated with that installing user. When the installing user is localservice you're likely to be in a mess.
If you need to do this, configure the service to run as a valid administrator account - that might give you a chance of it working better. It's possible that the failure to connect to server error is because MSI files are expected to be run from some kind of user account.
Open service management console Start->Run->Services.msc
Right click on your service and go to properties
On property page select second tab i.e. "Log On"
Check checkbox called "Allow Service to interact with desktop".
Harry Johnston is right, local service doesn't have the privileges to do that. Local system works great though, so i'll use a local system account.
Thank you for your answers, they were all helpful!
When I install my C# app in windows 7, UAC always shows. I'm not logged in as Administrator but I want my application to be installed without the UAC.
Can you give me ways on how to do it?
The UAC prompt shows for any number of reasons, none of which is "the code inside the exe calls function X or tries to write to place Y." These include:
the name contains setup, patch, update etc (eg setup21.exe) and there is no manifest
you embedded a manifest that asks for requireAdministrator. You would have done this on purpose in Visual Studio.
there is an external manifest (for NewApp.exe it would be NewApp.exe.manifest) in the same folder that asks for requireAdministrator. You would have done this on purpose too.
you have right-clicked the exe, and on the Properties Compatibility you have chosen to elevate it, or to run as XPSP2 which for 7 also elevates
someone in your company has applied a Group Policy that this installation app should run elevated (unlikely)
you once ran it, got a dialog from Windows saying "that may not have worked right" and agreed to try again with "recommended settings"
Do any of these seem likely? If so, correct them and see if the UAC prompt goes away.
Single Package Authoring link text
You'll want to use Windows Installer / Windows Installer XML to make this install behave the way you request.
If you want to install an app without UAC then you can only touch folders that the currently logged in user can write to. Google Chrome does this--it installs the entire application to the user's local application data folder.
It's very non-standard and I would argue MS should prohibit running code from this location, but it's a working solution to requiring administrator/UAC access to install applications.
Incidentally, Google Chrome more recently made a traditional installer available so one user can install it to be used by all users on the computer.
If you want your application to be installed without triggering the UAC, install to %APPDATA% (instead of installing to %ProgramFiles%) and write to the HKCU hive only in the registry (i.e. don't try to write to HKLM, HKCR, etc.)
I have an application that has drag and drop functionality to import images and video's. While developing, and testing through Visual Studio this has never given any problems.
After installing through a set up project, everything in the application works fine, except the drag and drop, which seems to be doing nothing. Are there any security settings that need to be set through an installer, or something of that nature that could be preventing drag and drop after installation ?
Yes, your drag+drop will not be permitted if your program runs with elevated permissions. It is called User Interface Privilege Isolation, Vista UIPI for short. It is complementary to UAC and controlled by the uiAccess attribute in the manifest entry that you'd use to elevate your process. As well as a certificate and a proper install location.
Realistically: don't elevate your program. It is a security hole when restricted programs can get their objects dropped in your privileged program. UIPI tries to prevent that.
But debug your program first.
Build a debug version of your application, build your installer with the output. You can either include the .pdb files in the installer or copy them to the install location after you install.
Run the installed application, and then in Visual Studio, go to Debug --> Attach to Process. Select the process from the list, and click the "Attach" button. Add breakpoints, etc, and debug as normal.
If you don't run into the problem on your build machine, you can also run a remote debugging session to debug the application on a different computer, but this requires a little more setup.
So, this interesting issue has been plaguing me for the past couple of hours. Visual Studio 2010 Ultimate no longer attaches the debugger and lets me debug my code.
If I use the built in development server, then everything works fine. If I switch to Use Local IIS Web Server (http://localhost/), then all it does it attach to w3wp.exe, but no DLLs or PDBs are loaded for anything. I can go to Debug > Windows > Modules, and literally nothing is loaded in this window. Conversely, when using the built in development server, the Modules window displays all the DLLs and shows that the symbols for my DLLs have been loaded. Something is obviously amiss. The VS installation is completely bone stock.
In IIS, my website is configured with ASP.NET 2.0 (because no 3.5 exists to select from the drop down), along with read / log visits / index this resource options checked on the "Home Directory" tab.
Some of my failed ideas:
1) If I attach to process on the iexplore.exe instance where the website is displayed, it loads Internet Explorer's DLLs, but not mine.
2) I've restarted the computer multiple times
3) I've invoked devenv.exe /resetuserdata once
4) I've confirmed that every project is indeed set to debug and not release.
5) Deleted all \bin contents and rebuilt the solution.
6) Deleted entire solution and repulled from Source Control.
Can someone tell me what is wrong with this thing? I'm going to have an aneurism from the headache this is causing me.
You need to attach it to the IIS worker process, which OS are you using? Make sure you attach with the Managed + Native flags, in the Attach to Process. What happens if you just run (F5) your web application inside Visual Studio (that automatically attaches a debugger)? Do you get any errors?
Well there are quite a few good answers here, but I have found that the root cause of the issue for me was application pool authentication configuration. Let me lay out the scenario that I experienced and the solution and perhaps it will help someone save time....and hair.
Scenario:
I want to debug an ASP.NET web application in Visual Studio 2010 but cannot use the built-in Visual Studio web server. The reason that I could not use the built-in web server is that my application referenced assemblies built specifically for a 64-bit architecture and the VS web server would not support these. So, I had to use the option "Use Custom Web Server" in the website properties to point the debugger at a published instance of my site on a remote IIS web server.
Issue:
Even with the web.config debug options set correctly to publish debug symbols in the assembly output (i.e. compilation debug="true"), the debugger would not attach to the remote IIS process and I did not hit any breakpoints
Environment:
The Visual Studio 2010 debugger was already installed on the remote IIS web server and was running as a Windows service under the LocalSystem account.
Solution:
Enable "Anonymous Authentication" in addition to "Windows Authentication" on the web site hosted on the IIS web server.
As soon as I enabled anonymous authentication, the correct symbols were loaded by the VS remote debugger and I was able to hit the breakpoints.
Hope this helps you guys out.
Have you tried deleting the browser cache? Sometimes the browser hangs on to old code which is incompatible with the current build and thereby prevents debugging.
Does it run the app - without the debugger attached? It smells like you are attaching the debugger to a wrong process
I've had an issue before where under the build configuration screen some projects are unticked for a particular solution configuration, causing them to not build and therefore not be debuggable. Can you confirm whether or not code changes you make are actually being built and executed?
Also, what version of Windows and IIS are you running? Is it possible that your process is running under an AppPool with an account that's different to the account you're logged in with and perhaps it's a permissions problem? If it's Vista/Win7, is UAC turned on and are you running VS as administrator? I'll also second the suggestion to try a fresh project and see what that does. Are you in the debugger users local group on the machine?
I want to run the remote debugger of visual studio 2005 in service mode.. It is running fine in application mode, and when in service mode it starts successfully but I can't connect from the remote system.. Is their any special setting required.. Please help me out.
Check which user you have it running under as a service. The remote debugger requires that all users involved have admin permissions on both machines. If you're running under something like the "local service" user it won't have the required permissions.
Start by trying to run it as the same user as you ran it in app mode. If that works you know that your problem is to do with permissions.
Also, try ticking the "allow service to interact with desktop" option. you probably won't want to leave it permanently like this, but it might allow it to report an error to you that will help you figure out what is going wrong.