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.
Related
I am trying to understand what Image File Executions Options can do and what it's normally used for. I know it is used for debugging purposes but how do I know its used for malicious purposes? Is this registry key used with every executable? If not, is it suspicious?
For example what does \Image File Execution Options\DevOverrideEnable do?
PS: I have looked a these sources already:
https://gooroo.io/GoorooTHINK/Article/17352/Image-File-Execution-Options-Good-Evil-Fun/28441
https://blog.malwarebytes.com/101/2015/12/an-introduction-to-image-file-execution-options/
Normally debuggers can run a process or attach to existing process to debug it and it's enough for normal projects but in some projects like services debugger can't start the service because of Windows service architecture. in this scenario we should attach debugger to running service process but if we want to debug some codes in startup of service we can't do it by this method because debugger attached to process after the startup codes executed.
In scenarios like this we can use Image File Executions Options (IFEO) by configuring to launch debugger when process start, when specified process start Windows launch process inside specified debugger and let developer to debug the process from beginning of born !
The problem of this option is Microsoft Windows do not (and cannot ;) check the specified debugger is really a debugge.
On the other hand malware authors use this option as a trick to start they malicious process when some process run, for example they can run a injector every time "explorer.exe" process run and inject some malicious code to it.
Finally IFEO is not malicious option by it self but maybe! and there is not simple way to know it's malicious or not. if you want to be sure it's malicious or not the debugger should be analyze and check manually for malicious activity.
If you are not computer skilled person the easiest way for you is to find the IFEO registry keys and find debugger's path from theme and upload debugger file to online scanner website like VirusTotal and hope they tell the truth :))
If I run a program using Start Without Debugging, I want to be able to terminate that process. I am looking for a key combination or option in the menu to be able to do this. How can this be done?
I am not talking about terminating the program while debugging.
I believe that there is no 'yes' answer for this question. When you start without debugging it just launches a new, separate process and as such, it couldn't be terminated from within a Visual Studio.
The only different scenario I could find here, is when you are working on a web project, for which VS is launching a hosting process (a HTTP server, like IIS Express). If you kill your VS then, it will kill the process hosting a web application, so it is a kind of dependent process.
But still there's no shortcut for that. So that means there's no such way from VS.
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?
I have a multi-threaded Windows application that occasionally deadlocks. Inevitably this happens on a customer system and not when the software is in test. What is the easiest way of getting a Windows Minidump of the current state of the application? If it could also terminate the application so the user can restart it and continue using the system that would be great.
In Vista you can create a dump file directly from task manager. Right click on a process in the processes tab and choose 'create dump file'.
Prior to Vista I prefer the ntsd route, since although it is not totally user friendly it works without the user installing any other software and the instructions are actually fairly easy to follow.
See the Microsoft support article How to use ADPlus to troubleshoot "hangs" and "crashes", as well as the helpful blog post Debugging Production Applications using ADPlus.
Both of these articles are about "ADPlus", a VBScript tool supplied with Debugging Tools for Windows that can be used to generate minidumps from a production environment (which can later be loaded up with WinDbg on your development machine). ADPlus has a lot of functionality and a lot of options, so it may take some reading, experimentation, and practice to find the best way to use it in your environment.
I know how to achieve this. It's just my technique is a bit clunky. All Windows 2000 and later systems have a basic command line debugger as part of the default install called NTSD. What I do at the moment is run:
ntsd -pn MyApp.exe
When the debugger console appears I can then type the following into the debugger console:
.dump c:\my-deadlock.mdmp
.kill
What I'm looking for is something that's a little bit cleaner and easier to put in an email to customers to just run. I've seen it alluded to somewhere (that google can't find for now) that you can use drwtsn32.exe to extract a crash dump and terminate an application.
Edit: It is possible to streamline the command somewhat:
ntsd -pn MyApp.exe -c ".dump c:\my-deadlock.mdmp; .kill"
The command .detach can be given if the process has not terminally hung (e.g. a long network timeout) and you want the process to keep going.
We are using VS 2008 Team System with the automated test suite, and upon running tests the test host "randomly" locks up. I actually have to kill the VSTestHost process and re-run the tests to get something to happen, otherwise all tests sit in a "pending" state.
Has anyone experience similar behavior and know of a fix? We have 3 developers here experiencing the same behavior.
This may be related to an obscure bug that causes unit tests to hang unless the computer name is UPPERCASE. Crazy, I know - but I had this problem and the fix worked for me.
Bug report on MS Connect
Workaround on MS Connect
TFS Blog Article about this issue
HowTo edit the registry to change your computer name
The easiest approach is to tweak the registry. You need to edit two keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName
Change value ComputerName to be upper case in both keys, and restart. Tests then magically work.
When you say lock up, do you mean VS is actually hung, or do the tests not run?
The easiest way to track down what is going on would be to look at a dump of the hung process. If you are on Vista, just right-click on the process and choose to create a memory dump. If you are on Windows XP, and don't have the Debugging Tools for Windows installed, you can get a memory dump using ntsd.exe. You'll need the process ID, which you can get from Task Manager by adding the PID column to the Processes tab display.
Once you have that, run the following commands:
ntsd -p <PID>
.dump C:\mydump.dmp
You can then either inspect that dump using WinDBG and SOS or if you can post the dump somewhere I'd be happy to take a look at it.
In any case, you'll want to likely take two dumps about a minute apart. That way if you do things like !runaway you can see which threads are working which will help you track down why it is hanging.
One other question - are you on VS2008 SP1?
I would try running the tests from the command line using MSTest.exe. This might help isolate the problem to Visual Studio, and at least give you some method of running the tests successfully.