When using WinDbg to debug an executable, is there a way to specify a batch script to run before debugging starts to set up environmental variables for the debug session?
I'm attempting to mimic an automated test environment where this executable will run. The variables contain information like what the current build number is, where the results directory is and where the 3rd party tools directory is located. I could hard-code these into the application for my own testing, but that's ugly :).
This is of course on a Windows OS, and I would rather not use a different debugger.
If WinDbg doesn't support this directly, what is the best way to achieve this functionality?
WinDbg's -o option causes it to automatically attach to all child processes, which is useful for debugging a program that is launched from another program. If you run windbg -o cmd.exe /c myscript.bat, WinDbg will debug cmd.exe (which you can skip over) as well as every child process spawned by that instance of cmd.exe. This might be annoying if the batch file runs a lot of other commands before running the one that you want to debug, but the sx* commands (e.g. sxn ibp; sxe ld:mymodule) ought to be able to reduce the annoyance.
Another approach is to use the Image File Execution Options registry key to attach WinDbg (or cdb/ntsd) whenever your EXE is launched.
Related
I would like to debug a C++ program in VSCode. The problem is this program is run as part of a large and messy build system that spawns many processes and prepares input for the program. In other words if I run:
./do the_task
It will compile a load of C++, generate some input and eventually - through several layers of Bash, Python and Makefiles - run something like this:
/very/long/path/to/the_task --lots --of --arguments /very/long/path/to/generated_input.xml
I'd like to debug that process using VSCode/GDB, in such a way that I can
Set breakpoints in the_task.cpp
Just click "Start debugging" with the launch.json set to run do the_task
Unfortunately that doesn't work because by default GDB doesn't follow child processes. You can tell it to but then it will halt the parent process so that only a single process runs at a time. That causes everything to get stuck at some point in my case.
Some ideas I've had:
Is there a way to tell GDB to run a script when a new inferior (process) starts, check the executable name and then detach from the child if it doesn't match?
I could create a proxy GDB/MI wrapper that pretends to VSCode that the program has been started (so the connection doesn't time out), and then when we get to running /very/long/path/to/the_task prefix it with gdb --interpreter=mi and forward on all of the cached commands (to set breakpoints etc.) This seems like quite a lot of work and quite hacky so I'm not sure I like it.
Prefix /very/long/path/to/the_task with gdbserver. Then I can connect to it from VSCode. This is definitely the simplest and most obvious solution but the UX sucks - you have to manually start the command, then wait, then click "start debugging". Plus you're inevitably going to run into port reuse annoyances.
3, but write a custom VSCode extension that automatically starts debugging when it detects gdbserver has started. I've done this for Python debugging so it does work but there are some minor annoyances (e.g. if you restart VSCode and it restores a terminal session it doesn't work). Also it's a fair amount of work.
Is there an obvious solution I'm missing?
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 batch file that toggles aero. Is there a way that when you open a certain program the batch file will run when it is launched and run again when the program is closed?
Well yes, but on the Properties for the program you can tick a checkbox to do this on the compatability tab.
Find out info on what the browser is doing. Sart your program and then use Task manager to find your game (it is a real game and not some jscript web thing?).
Compatability layers are scritable.
See http://support.microsoft.com/kb/286705
set __compatlayer=256Color (note wrong spelling)
Running a program will have same problem as setting compatability. You have to find something to run it on.
Windows can start a debugger automatically when a program is started. You can substitute any program that can start a program (as a batch can) for the debugger.
You can also run a script that triggers on program start. Task Scheduler can run tasks when certain events occur.
But you have to know what exact object to trap. Use task manager in the first instance.
I have created simple exe to perform a task using VB6. I have deployed the same on Windows Server 2008 as task scheduler. The issue is when the user is not logged in on server, task fails to execute.
I have kept option to "Run whether user is logged on or not", still no use.
How do you know that it doesn't run. Task Scheduler keeps a history of what happened.
Most programs have some dependecy on the user profile and the user's configuration.
More likely your program is crashing. Look in TS's History tab. There's a general one and a task one.
How do you know that. You can't see it so you can't know. Many programs won't run if not logged on. If you check a setting, try to use a mapped drive, write temporary files in certain ways your program won't work.
It's irrelevent that it works when you are logged on.
Try it with psexec from Sysinternals. This can run programs as system (unlike RunAs command). See what happens when you run it as system.
http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx
Whatever we need an error number. If your program doesn't have much error reporting then run it with windbg.
psexec -s windbg "c:\yourprogram.exe"
You can also start in a debugger.
windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srvC:\symbolshttp://msdl.microsoft.com/download/symbols
then
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
Type lm to list loaded modules, x ! to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Also CoClassSyms (microsoft.com/msj/0399/hood/hood0399.aspx) can make symbols from type libraries.
.
This question already has answers here:
How can I use DebugBreak() in C#?
(5 answers)
Closed 2 years ago.
I'm using Windows Scheduler to run an exe I have written.
How can I jump into a debug session when the scheduler starts my exe?
Update 1.
I had thought of doing a Thread.Sleep and then Attach to Process. When I tried it, it says Debugger is already attached to process...
You could just call DebugBreak() from within your program.
According to the MSDN page, DebugBreak does the following:
Causes a breakpoint exception to occur
in the current process. This allows
the calling thread to signal the
debugger to handle the exception.
To cause a breakpoint exception in
another process, use the
DebugBreakProcess function.
You can then attach your debugger at this point, and continue running the program.
The only problem with this solution is that you need to make the DebugBreak() in the code conditional, so that it won't break every time the program is run. Maybe you achieve this through an environment variable, registry setting, or a parameter which the scheduler passes in to the program to ensure that it breaks when it starts up.
Example code
Here's some untested example code reading an environment variable:
int main()
{
char *debugBreakChar = getenv("DEBUG_BREAK");
int debugBreak = atoi(debugBreakChar);
if (debugBreak)
{
DebugBreak();
}
// Rest of the program follows here
}
Now all you need to do is set the environment variable as a system variable, and ensure that it's accessible from the same shell context as the scheduler (rebooting will achieve this):
set DEBUG_BREAK=1
Now the program will break on startup, allowing you to attach a debugger. Changing the environment variable to 0, or un-setting it, will allow the program to run normally.
Environment variables are a bit fiddly in this regard, as they are context-based and you need to know that the scheduler runs from the same environmental context. Registry values are better than this, and you can read a registry value using RegQueryValueEx in your code instead (you'll need to include windows.h to use this function).
Attach to Process will work (from within Visual Studio), although you may need to add a sleep statement at the beginning of your code if it is a fast process so that you can attach before it starts your main logic.
You can set a key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options that will attach debugger to the process when the process is launched. You can read how to do this in this KB Article.
There are couple of gotchas with this approach:
IFEO debugging does not work with pure managed debugging. You need to use Interop Debugging
You might need to remote your debugger to another session, depending on what user the Scheduler launches your app as.
To debug using VS, you need to actually specifyg VSJitDebugger.exe in the IFEO options for your executable. You will also have to specify the debugging engine to use manually. More details here.
"Attach to Process" in Visual Studio's Debug menu.