When launching a program from Visual Studio 2012 in debug mode (using the "Play" button), my application fails at a certain line of code. For the sake of being specific, the error I'm receiving is:
Method Open threw an exception. Could not create a service object instance, or could not get its IDispatch interface.
However, when I run the application by simply launching the EXE by clicking on the file name, I do not encounter this error.
Additionally interesting is the fact that I can add the following statement to my code (causing the debugger to attach AFTER launch) and I do not receive the exception I mentioned above.
if(!Debugger.IsAttached) {
Debugger.Launch();
}
So, in short: When Visual Studio launches my program, there is SOMETHING different about the processes permissions / rights, app domain, or other factor that is changing its ability to operate "normally". I know that the parent process of my application when launched from Visual Studio is the devenv.exe process, could that have anything to do with it?
Some troubleshooting I've done:
I have disabled the Visual Studio Hosting Process to eliminate that from being a potential issue.
I've inspected the process in each different testing scenario listed above in Sys Internals' Process Explorer. I've compared permissions, session, user name the application was launched under, and many other things to attempt to find a reason why the application would function differently. All comparisons come up identical with the exception of the parent process (explorer.exe when launched manually and devenv.exe when launched through Visual Studio)
Any ideas?
Update:
I did another test and selected Debug -> Start Without Debugging, which DID NOT produce the error specified, but still launched the program with its parent process being devenv.exe which rules out that as being a potential issue. So its something to do with the debugger being attached right from the start of the program.
Related
I have a myapp.exe that after some complicated logic is run by another program. I wanted to debug the issues with myapp.exe just like visual studio preferably using breakpoints. What is the way to achieve this? The exe is a console application and is run on the spot. It's not a running process so I cant attach a debugger.
The expected behavior I would want is:
Do magic and set breakpoints for that exe and dlls
Call the exe from the other program
Visual studio hits the breakpoint and I can debug what is going on
Just use System.Diagnostics.Debugger.Launch() where you want to attach the debugger. You can place it just before your desired breakpoint location. Windows will ask you what debugger do you want to attach.
Another way is to check the System.Diagnostics.Debugger.IsAttached property and wait for the debugger like this (polling):
while (!Debugger.IsAttached)
{
Thread.Sleep(500);
}
The application will loop until you attach the debugger (in visual studio via attach to process command, Ctrl+alt+P ).
Again, just place a break point after or even in the loop and you're done.
This is a well know way used to debug a windows service application and can be useful also for your intent.
Is it possible to simulate non-UserInteractive mode when debugging in Visual Studio, and if so, how?
I have a service that is running that I'd like to debug, but the behaviour is different depending on whether I'm debugging it or running the service.
I found this question:
How do I debug Windows services in Visual Studio?
The answer there doesn't quite do it for me because following that, when you debug it, the debugger runs the process in UserInteractive mode. What I want is the debugger to debug the process, but without UserInteractive mode.
For example, I had an error that was buried deep in the code because a library it uses was trying to display some sort of dialogue box (even though the dialogue box wasn't seen by the user). This would not be picked up in Debug because UserInteractive mode is used. I want to be able to do more debugging on these kinds of issues
To debug a service you would need to
Build your service in the Debug configuration
Install your service to see how to do this go to this link https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-install-and-uninstall-services
Start your service either from services control manager, server explorer or even from the code and if you want to know how to do this then go to this link https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-start-services
Start visual studio as admin so that you can attach to system processes.
Optional > on visual studio menu bar, choose Tools, Options. In the options dialog box choose debugging symbols and select microsoft symbol servers check box, and then choose the OK button
On the menu bar choose attach to process from the debug or tools menu for the short key press CTRL+ALT+P
The process dialog box appears
Then select the show process from all users check box
In the available process section, choose the process for your service and then choose attach
Hope this helps
I hate attaching to a process from Visual Studio. It works, but it also seems to take forever to build the list of processes to choose from. Perhaps that's because our systems are locked down too tightly. It's entirely possible that in a different environment, this works just fine.
Still, I find it much easier just to trigger a programmatic breakpoint when the service is starting and jump in to debugging at the beginning. To do this, call the following in the OnStart() callback:
System.Diagnostics.Debugger.Break();
When you start your service, you should get a prompt indicating an unhandled exception has occurred.
Click the Yes option, answer Yes to the UAC prompt, select which instance of Visual Studio you want to use, and then debug normally once Visual Studio starts.
When you're finished debugging, just stop the service, and the debugger will quit automatically. However, don't close that instance of Visual Studio. Make whatever changes you need to make the service, and rebuild it. Then when you restart the service and you get to the point of selecting the Visual Studio instance to use, it'll include your original debug instance in the list. It's much faster to jump back into that one than creating a new instance each time.
HTH
Seems like a simple question but I am facing some weird problems.
I am using Visual Studio 2015, Enterprise Edition and Install Shield to create setup of my software, this is my first time making a general purpose software. Everything goes according to plan but I get these 2 problems.
Problems are:
Shortcuts don't work
Application doesn't launch until I run from root directory as admin
Problem 1:
I create the setup and do everything asked, I put the primary output into setup, which by the way contains 2 files. the .exe file and a .config file and I choose the primary output in "add" button to create a shortcut but when I install that setup, the Desktop shortcut doesn't work, in no way.
Problem 2:When I simply double click on the software's main .exe file, it doesn't run. No response but when I run it as Admin, it responses and opens. The problem is weird cause this doesn't happen in debug or the release files of the software.
Is there something I am doing wrong? maybe the way I insert the primary output?
This doesn't appear to be an installation problem. Your statement "..when I run it as Admin, it responses and opens" means that your program requires admin privilegs to run correctly, and running it from a shortcut does not automatically run it as administrator. The usual way to say that a program needs elevation when it runs is to give it an elevation manifest as here:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
with requireAdministrator. The program will then show the standard dialog requesting elevation.
The most likely reason for your program doing nothing when it fails is that it silently crashes and goes away, and that's probably because your code isn't explicitly making sure that everything you do is actually working. For example, if you try to create/modify a file in Program Files (and you're not elevated) it will fail, and your code should check that access was denied.
Pls don't mark it as duplicate .. bcoz I have seen all the solutions but nothing is working for my case..
I have two machines devMachine and serverMachine
in devMachine I am developing application with Visual Studio and Now I have a simple Console Application..my need is I need to run this Console Application in serverMachine and debug from devMachine via Remote Debugging.
As told in Microsoft document, I have installed Remote Debugging tool in serverMachine and set the Authentication mode as Native (No Authentication) and run the Console Application in serverMachine.
Now , I have attached the remote process in devMachine's Visual Studio. All are working fine
But only problem is breakpoint is not hitting in Visual Studio
Note: I have placed required .pdb file in serverMachine and set that .pdb file path in devMachine's Visual Studio (Tools->Option->Debugging->Symbols).
Can anyone help me to resolve this issue?
What does the error message on the breakpoints say (if you hover over the breakpoint) - that it's different from the source? --> You can try disabling (from Tools/Options/Debugging) - Enable source file to exactly match the original version
What does the Modules window say - do the PDB's appear as loaded? if not, have you tried loading them manually (from the Modules window, right click the PDB and load)? - Is there an error message if it fails?
--> you might be in a case where the source files in the local machine are different from the ones on the remote one. Try copying everything over and see if that works (PDBs would be in the same folder as the EXE)
There are two reasons for the remote debugger to not hit the breakpoint
Wrong symbols.
Using the wrong .Net framework while debugging ( you can select on the "attach to process" window in visual studio).
Don't attach and just set remote debugging on. Copy all the project files to the identically placed and named folder in the server during post-build.
I had an issue with Visual Studio not breaking at my breakpoints although it looked like everything was setup correctly for the remote debugger on an IIS machine. I searched everywhere for an answer. The issue finally presented itself when I tried to manually attach the VS debug to a process (VS menu --> Debug --> Attach to process...) For some reason, there were multiple processes for the same application pool (there should only be one process, not sure where the others came from) I logged into my IIS server and killed all the processes for my application pool and then restarted the IIS application. When I saw there was only one process for the app pool (as I expected), I tried debugging in Visual Studio and it attached to the correct process. It turns out that when there were multiple processes for the same application pool, it attached to the "wrong" one.
Looking at your screen shot, could it be simply because the break points are in the "main" function which could already have finished before you can attach the debugger?
Suggestion:
Maybe put some artificial wait/delay code of say 20 secs in "main" above the first break point to give yourself enough time to attach to the process before "main" completes.
I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.