I would like to synthesise a native code fault. This is so that we can see where in particular some debugging output gets put when that occurrs.
Pskill (from Sys-Internals) causes a graceful exit. DotCrash.exe doesn't seem to be available anymore from Microsoft directly.
Is there any way to externally cause a crash in a process?
I've done this before using windbg by:
Starting the process
Attaching to the process with windbg
Setting a breakpoint on one of my app's functions
Running the app until I hit the breakpoint
In windbg setting a local variable to something that will cause an Access Violation (e.g. set a pointer to 0xFFFFFFFF or muck with the register values)
hit f5 and the app should hopefully crash
If what you want is the equivalent of a coredump, drwtsn32 -p ProcessId generates a dump of the current state of a running process. If you have the appropriate debug symbols you can get valuable information.
HTH.
As Nick mentions, this can easily be done via Debugging Tools for Windows - I'd go one step further though, and use cdb (the command-line WinDbg) to script the whole interaction.
If you need dumps at any desired time, you can use Microsoft's free debug diagnostic tool which has a nice UI to do that or on command line drwtsn32 -p processid as recommended by jrbjazz.
You could try using CreateRemoteThread. Using it correctly isn't easy, but making the other process crash should be pretty easy ;-)
Could you install some kind of hook function, or use something like the detours library?
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 :))
I have a process that is already running, and I want to debug it with GDB. I've been using
gdb --pid $PID
However, when I do this, the process pauses. I'd like to attach to the process without pausing it, and look around in its memory while it's still running. Is this possible? Alternatively, is there a way to "fork" the process so that I can look at its memory, without stopping/pausing the process?
There's no way in gdb to attach without some sort of pause.
The Linux kernel provides some support for this via PTRACE_SEIZE, but gdb doesn't use this yet. There's a bug in bugzilla you can track, "Bug 15250 - use PTRACE_SEIZE and PTRACE_INTERRUPT"
Meanwhile you could try setting gdb into "observer mode". Then you could attach and use continue & to continue the process in the background. You may need to set various settings, like target-async, depending on the gdb version.
I am not totally certain if this will work. It is worth a try. Note that there is a window in which the program will be paused. This is unavoidable right now.
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.
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.
1.exe doesn't give enough time for me to launch the IDE and attach 1.exe to the debugger to break into.
I would suggest taking the same approach as with NT services in this case. They will also start and usually not give you enough time to attach the debugger for the start-up routines.
Details are described here: http://www.debuginfo.com/articles/debugstartup.html
In short you add a registry entry for the second exe:
HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution
Options\2.exe Debugger =
"c:\progs\msvs\common7\ide\devenv.exe
/debugexe" (REG_SZ)
Change the c:\progrs\msms\ to match your settings.
Hope that helps.
I assume you have the source to 1.exe (if you're debugging it), then just insert a statement near the beginning that will cause it to hang around long enough to attach a debugger. ( getch() if you're desperate and it's not interactive. )
After the attach, just skip to the next statement and let it go.
You could put in some preprocessor commands for debug builds - just remember to build your release in release mode:
#ifdef DEBUG
Thread.Sleep(10000);
#endif
How is 1.exe launched? If you can launch it using CreateProcess(), you can start the process in a suspended state, attach the debugger, then release the new process.
If you are willing to consider a debugger other than Visual Studio, WinDBG can auto-debug child processes (native code only).
You did not mention what language you are using. But if you using C# or VB.NET you can add Debug.Break() or Stop to trigger the prompt to attach debugger to the process.
Or as mentioned above just use something like Console.Readline() or MessageBox.Show() to pause starting of process untill you can attach debugger to it.