I am trying to fix a bug on an ActiveX control. Is it possible to debug it from within Visual Studio 2008?
If attaching to the process is a problem, just throw a DebugBreak() into the code you wish to debug. If VS is your JIT debugger, once the debug break command is reached you'll be asked whether you'd like to debug the process. Just say yes, and you're in.
You should attach the debugger to the process which loaded the ActiveX component. If the latter has debug information you will be able to debug it as if it was a usual application.
If the host application refuses to load it and you suspect that some code responsible for the ActiveX initialization is broken you can attach to the process in advance and them do the action that will make the host application load the ActiveX.
ActiveX is not a stand alone application.
Usually, it is used within a container application.
I suggest using the Message Boxes and alerts.
Hope this will help.
Related
i want to do statistics on cpp programming action so i decide to develop a plugin with Visual Studio SDK. Now i encounter a problem. I want to know the running state of the cpp program. e.g. when user launch the program? when the program end? or whether the program runs successfully.
i have read a part of api references on msdn. i have just found dte.debugger and Ivsdebugger to get debug info.but i cannot find api to get normal run states.
can someone give me an idea? thank you very much.
i have solved it. in VS, debug run or normal run is treated as the same. they all trigger debug event. i can tell normal run from debug run by analysing the debug target.
I'm trying to debug some web services. I have a number of integration tests setup. I want to attach the debugger to my web process and then execute one of my tests. The problem is Visual Studio doesn't seem to allow me to run a test while I'm already attached to a process. Is there any way around this? The only way I've been able to do it is set a breakpoint in the test prior to calling the webservice, debug the unit test, and then once it hits the breakpoint attach the debugger to my webservice process. That's too many steps.
No I don't believe you could. You can however start up a second instance of visual studio and attach it to your web process with the appropriate breakpoints.
I know this is late but it's still relevant, at least up to VS2019.
What I do to work around this is this:
Attach the debugger to my web service
Detach the debugger
Take note of the 'Reattach to process' shortcut. I think the default is Shift+Alt+P
Run the unit test
Immediately hit the reattach shortcut
Unless your test starts up exceptionally quickly, this method will reattach the debugger before the tests start running.
Allen's answer is better if your machine can handle 2 instances of VS.
I'm using VB Express 2008. I know how to tell if code was built in debug more or release, but now I would like know how to tell if it is running in the Visual Studio IDE or not (so that I can add some debug MsgBox() and not worry about them showing if I ever accidentally ship a debug version).
Is System.Diagnostics.Debugger.IsAttached what you're looking for?
If you're building for Test and Prod, consider using a preprocessor directive in your code.
#If DEBUG Then
MsgBox("Foo")
#End If
This falls down, of course, if you ship a debug-built binary to a non-dev environment. I understand this is attacking the problem from another angle from where you asked the question (the IDE).
Try checking the IsAttached property of System.Diagnostics.Debugger
If you want to make sure you never show debug messages to users, you can use Debug.Write() and Debug.WriteLine(). These commands will output the text supplied to the debug output window. Note that you can attack a debug output window to a program running production code on a customer's machine without installing a development environment!
Testing for an attached debugger does not indicate that the debugger is also inside an IDE. It is quite common in many environments to attach debuggers to production code running on a customer system to identify what is going wrong on a particular customer's installation and usage. Testing for a debugger and then presuming you are in an IDE will foul out this usage of debuggers in a production environment.
I'm trying to attach to a remote machine with code similar to the following:
Debugger2 db (Debugger2)dte.Debugger;
Transport trans = db.Transports.Item("Default");
Process2 proc2 = (Process2)db.GetProcesses(trans, "MACHINENAME").Item("SERVICENAME");
proc2.Attach2();
I've gotten it to work by logging on through remote desktop and manually starting the debugger, but I have to stay logged in. The problem is, I don't want to stay logged into the remote machine. Is there a way to automatically launch the debugger, similar to what happens when I attach through the IDE?
You could wrap your debugging code as a Windows service that executes at startup with hightened privileges.
However, I don't recommend that route, because based on experience I think it's over-kill for what is most likely needed. Could you expand on why you want to attach a debugger to a remote process automatically?
My guess is that you want to do something that would be best suited for WinDbg. Something similar to these.
Enabling windbg to break on clr exceptions
Configuring a service to start with windbg debugger attached
But, without more background information on what you are trying to accomplish, I'm obviously just guessing.
I am working on an ASP.NET web application, it seems to be working properly when I try to debug it in Visual Studio. However when I emulate heavy load, IIS crashes without any trace -- log entry in the system journal is very generic, "The World Wide Web Publishing service terminated unexpectedly. It has done this 4 time(s)."
How is it possible to get more information from IIS to troubleshoot this problem?
Download Debugging tools for Windows:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows has has a script (ADPLUS) that allows you to create dumps when a process CRASHES:
http://support.microsoft.com/kb/286350
The command should be something like (if you are using IIS6):
cscript adplus.vbs -crash -pn w3wp.exe
This command will attach the debugger to the worker process. When the crash occurs it will generate a dump (a *.DMP file).
You can open it in WinDBG (also included in the Debugging Tools for Windows). File > Open Crash dump...
By default, WinDBG will show you (next to the command line) the thread were the process crashed.
The first thing you need to do in WinDBG is to load the .NET Framework extensions:
.loadby sos mscorwks
then, you will display the managed callstack:
!clrstack
if the thread was not running managed code, then you'll need to check the native stack:
kpn 200
This should give you some ideas. To continue troubleshooting I recommend you read the following article:
http://msdn.microsoft.com/en-us/library/ms954594.aspx
Crash dump of asp.net process should give you tons of info..If you want to quickly get some info on why the process got recycled, try this tip from Scott Gu..
Health monitoring feature of asp.net 2.0 is also worth looking at..
The key is "without any trace". You need to put your own trace logging in to create some chatter. Then you'll be able to spot where the chatter stops.