Working on virtual machine environment, I'm using DbgView to obtain my printout log messages using debug_wsting
However, Working on large number of processes that produces those messages seem to consume lot to cpu and eventually halt the VM, So I'm looking of a way to offload this activity to the machine that runs this VM.
Perhaps there's a way to output the logs to remote windbg ?
Is there anything to configure on Client/Server ?
thanks
I never tried it on my own, but it's described in Windows Sysinternals Administrator's reference (Amazon). I thought I knew the Sysinternals tools quite well, but it turned aout I learned a lot. Totally worth reading.
To perform remote monitoring, DebugView runs in agent mode on the remote system [...]
To do so, run DbgView /a. Add /k if you need kernel messages as well and /gfor session 0.
[...] sending debug output it captures to a central DebugView viewer that displays the output.
and
To begin remote monitoring, press Ctrl+R or choose Connect from the Computer menu [...]
Be careful not to connect multiple viewers to a single computer because the debug output will be split between those viewers.
So, the output is there only once and after whatever machine fetches it, it's gone. Sounds normal.
Related
I am doing some analysis work on some software we are running where I work. The software seems to have memory issues some where along the line which are proving difficult to track down. We have decided to use Sysinternals VMMap to track the memory being used by the software.
We have VMMap exporting the usage every 20 seconds using Windows scheduler to launch a batch script which pulls back the target process PID and launches VMMap with it. The process runs for a while, output appearing the out directory but after a while it stops. Windows scheduler reports the job ran fine and will start another instance when the trigger is meant, once again with no output.
After a bit of investigation it looks like VMMap is failing to open the process and is trying to report an error through its GUI. Since we are running in batch, we cannot see this error to dismiss it. This is causing numerous process' to be spawned but not actually doing anything.
Has anyone come across this issue when using VMMap, or know of anything that may help? I am thinking there may be some flag I can pass which suppresses messages or maybe some way I can handle it in the batch but Google hasn't helped nor has the Sysinternals forum. Any help would be really appreciated.
VMMap is a GUI tool, so trying to capture its output in an automated way will be difficult. Instead, try using another SysInternals tool, Handle, that captures a lot of the same information, but exports/reports on it in command line, where it can be captured much easier. Alternatively, don't run the output in an auto-repeating way when using VMMap, but instead have your script somehow detect the error or missing expected results/data and stop so the GUI output can be examined.
All Sysinternals tools do pop up a consent dialog for the first time they are started on a new machine to accept their license. I think you did deploy the tool to a production machine and it was trying to show the consent dialog but nobody did press ok.
They do basically create a registry key on the machine which you can fake if you need a fully automated deployement or you can start in once on the target machine for the user in question.
when I download a program I want to know the many behaviour of this new program, i.e., does it connect to internet and sending my local computer data to somewhere, and what the system resources/functions have been called and what the new data/settings have just been written to my computer. Often than not Windows doesn't notify me all these actions, So I want to know it myselft, is there any possibility I can do that?
Thanks!!
You can use ProcMon for exactly that.
Process Monitor is an advanced monitoring tool for Windows
that shows real-time file system, registry and process/thread activity.
The newer version includes network activity monitoring too.
In fact you should take a look at the Sysinternals Suite since there are many other tools included in the suite like Process Explorer or TCPView that can help you with this task.
As for network packet inspection you can use Wireshark since the Sysinternals tools don't provide packet content inspection too(they mostly provide connection details and packet lengths).
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.
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.
What is your favorite technique for launching a windbg user-mode remote debugging session?
Why is do you prefer this technique over other techniques? (pros/cons)
There are at least four different ways to do user-mode remote debug using windbg, as documented in the "Remote Debugging" section of the debugging tools for windows help file.
run app on target then attach to it from the host windbg
have the host windbg use remote.exe to launch the app on the target
have the "smart client" host windbg launch the app on the target via a process server that is running on the target
run a windbg instance on the target machine using the option "-server" to automatically start a server, then connect to the server from a 2nd machine.
Option 1 is my favourite because it is the simplest. I get to launch the app in the normal way without worry about getting WinDbg to set the right working directory, pass any command line arguments, etc.
Fortunately I've not run into any cases where this hasn't worked!
There is no "the best" solution. Each of the possibilities has advantages and disadvantages and it's good to understand all of them. It depends on several factors like:
where are the symbols located
which PC has access to the Internet to download the OS symbols
what amount of data may you copy to the server (clients often accept better if it's just a single Exe)
what's the bandwidth between client and server
do you need other commands that just CDB/WinDbg, e.g. access to CMD, then consider remote.exe
who's available on the server side, a debugging expert whom you can easily tell a lot of cryptic commands or a normal user who barely knows how to start a command prompt
are both sides in a private network, so you need a "man in the middle" server to be able to access each other (or port forwarding as an alternative, which IT guys don't want and it may take days to get it set up)
From those 4 options, don't forget that clients often want to see exactly what you do, so they require an RDP session, Teamviewer or similar. That's something they understand.
I tend to use option 4 (-server) because it is the only one that doesn't "pop" when you break into the kernel debugger long enough for the TCP connection to timeout. But this is more complex and not fully satisfying. So I'm looking for "best practices".