I'd like to add logging to our unit tests that records the DLLs they use, and where they're loaded from.
I can get the information I need from Sysinternals ListDLLs, but I'd need to run that while the test process is running, and I'd end up with race conditions: for instance, ListDLLs could run too early, and miss a DLL that's loaded half-way through the test run; or ListDLLs could run too late, after the test process exits.
Similarly, I can get the information I need from the Visual Studio debugger's Output and Modules windows, but I'd like to automate this on our build server.
Is there any command line tool that can run an arbitrary EXE, track the DLLs it uses, and log the information to a file?
You may write your own tool, which will use "debugging" features. This tool must
Start new process suspended
Attach to created process as debugger
Process debugging events, as I remember, you need LOAD_DLL_DEBUG_EVENT
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679302(v=vs.85).aspx
The good news: it's not too hard to write it yourself using Detours. Hook the LoadLibraryA/W functions and log DLL names to a file (using GetModuleFileName against the value that the real LoadLibrary returns). Also hook CreateProcess, so that you can log DLLs loaded by child processes.
The bad news: I'd like to be able to post the source code that I used, but it's an internal tool that I won't be able to share.
Edit: I'm not convinced that this tool's Detours hooks are completely reliable, as during my testing, it's missed a few DLLs. Here's an alternative tool using the debugger API: https://github.com/timrobinson/logdlls
Note that SysInternals (now MSFT: http://technet.microsoft.com/en-US/sysinternals) has a great tools for tracking all sorts of events happening when loading your application: Process Monitor. You will have to filter out anything that is not related to the application you are examining. Also, you may want to set Operation="Load Image" filter.
Tried Tim Robinson's tool, but it seems it will only track Windows related dll's so not useful in my case.
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 :))
Al right! This might sound crazy.
I want to know if it is possible to see the code or something that a specific process is using. I have a scheduled task that is supposed to be ran by a process. The font end to this app says that the scheduled task executed successfully, but I don't see anything in the logs.
I want to know if there is a tool to see what a process is doing.
The best suite is Windows Sysinternals by Mark Russinovich (now bought by Microsoft).
Get it here.
Use Process Explorer.
Ever wondered which program has a
particular file or directory open? Now
you can find out. Process Explorer
shows you information about which
handles and DLLs processes have opened
or loaded.
The Process Explorer display consists
of two sub-windows. The top window
always shows a list of the currently
active processes, including the names
of their owning accounts, whereas the
information displayed in the bottom
window depends on the mode that
Process Explorer is in: if it is in
handle mode you'll see the handles
that the process selected in the top
window has opened; if Process Explorer
is in DLL mode you'll see the DLLs and
memory-mapped files that the process
has loaded. Process Explorer also has
a powerful search capability that will
quickly show you which processes have
particular handles opened or DLLs
loaded.
The unique capabilities of Process
Explorer make it useful for tracking
down DLL-version problems or handle
leaks, and provide insight into the
way Windows and applications work.
I'm not sure which technology you are using, but you could try to remotely debug the application the application, for example using Visual Studio. But to be able to do this you'll need the correct debug information files (.pdb).
If this is your own application you are trying to monitor, inserting some extra logging of some sort will be the easiest solution.
Another option you have is to make a memory dump at the moment you think the application is running. A memory dump is basically a snapshot of the entire memory. YOu can then use a tool like WinDbg to examine the contents of the dump.
Maybe you can give us a little bit more information?
I need to find out exactly what files/directories a Lua program uses so I can try to only pack what it needs into a ZIP file, and come up with a simple way to deploy this script.
I used SysInternals' Process Monitor, but I'm surprised by the small amount of information it returned while it watched the program (For Lua users out there, it's wsapi.exe, which is the launcher for the light-weight Xavante web server).
Does someone know of a good Windows application that can completely monitor what a program does, eg. something like a live version of the venerable PCMag's InCtrl5.
Thank you.
Process monitor will catch everything. If it's not catching the action then it must be happening in a different process. Try filtering based on the files you expect to be used rather than the process you expect it to happen in.
I have a Windows Service and I would like to see what it's doing when it starts up. Normally to accomplish something like that, I'd hard-code a Thread.Sleep for like 10 seconds to give me enough time to attach the debugger. This is effective, but annoying, as I need to re-compile once to put the pause in and again when I (hopefully remember to) take the pause out. I know I could alternatively hard-code a break command in, but that also requires me to re-compile my solution.
I know I can also separate my service's logic into a separate project that can be run in Visual Studio, which I can use most of the time, but sometimes I want to see exactly what my service is doing when it's running as a service.
Is there a way that I can get my debugger attached to my service so that I can see the things it's doing on startup, without hard-coding and re-compiling anything?
There is a registry key which gives you a chance to attach a debugger to the process as soon as it is created.
Save the following snippet as a *.reg file and import to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\services.exe]
"Debugger"="c:\\Program Files\\Debugging Tool For Windows\\windbg.exe"
remember to change 'services.exe' to the actual services executable file name.
You can also use the gflag tool to facilitate the work. For detailed information please check KB 824344: How to debug Windows services
Take a look at Attach to a process on the Tools menu in Visual Studio. You can put a break point in your code and then start the process and debug the service. You may have to put a thread.sleep() to give you enough time to react.
You have to start the service than attach to the process in Visual Studio. The thread.sleep() will give you the time to perform the attaching without blowing by your start up code.
Here is Microsoft's advice on how to accomplish this: http://msdn.microsoft.com/en-us/library/7a50syb3%28VS.80%29.aspx
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.