I'm putting together a USB drive that should contain tools useful for troubleshooting various software problems encountered by users.
What tools would you recommend that I include?
Main environment: Windows and .NET
I can recommend the following : {Some of them have been already mentioned though}
LOG ANALYSIS:
TextPad
NotePad++
VIM {for opening very large txt files}
SYSTEM MONITORING:
Process Explorer {allows to check the threads and dlls loaded}
CODE/ERROR ANALYSIS:
Reflector
DebugView
WinDbg
Autodump+
KeePass for all the different passwords used by your customers.
Any application-specific scripts you've built up (SQL, batch files, PowerShell etc).
Angry IP Scanner
PSTools from Sysinternals
If you're .NET you should get Reflector
SysInternals Suite, especially AutoRuns, Process Explorer, and Process Monitor
http://www.sysinternals.com
"DebugView is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don't need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs."
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
Related
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).
A few of my users have problems starting up my Java application on Windows XP and 7. I cannot reproduce the bug on my systems.
On Mac, the next step would be to ask them to send their system profile to me by going to Apple Menu > About This Mac > More Info and then saving the system profile.
Is there an equivalent on Windows? I would love to see:
Version numbers for the system
Hardware configuration
Shell paths: $HOME, $APPDATA, $LOCALAPPDATA
Drive layout
Programs running on startup
Loaded drivers and DLLs
Possible system logs
The built-in "System Information" tool in Windows provides most of what you want, and a lot of other useful information. No System logs though.
Have your users run "MSINFO32" from the start menu. Then File -> Export if you want a text output, or File -> Save... if you want a file that you can open with MSINFO32 on your end.
Whenever I'm debugging on a webserver (Windows) DebugDiag is good for memory/dll issues. You can load the crash dumps right into WinDBG.
For the system information, you will probably have to write your own script to collect this. WMI should let you collect the remainder of the system settings.
Here are a couple of possibilities that get part way there. The PsTools suite from SysInternals has a number of command line utilities that might be useful for this. In particular psinfo (system information) and pslist (running processes). Also, Process Explorer could be useful too since it has an option to save information to a file.
I want to know the files a given process is reading/writing. Is there a program that shows this? On Windows XP. Thanks. I've tried Autohotkey Spy, Spy++, and Process Explorer. They show a lot of detail but not which files are being accessed.
Process Monitor
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines
the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements
Filemon
Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.
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.