I'd like to write a debugging/diagnostic tool which can call Windbg functions to examine a dump file, instead of writing a windbg extension. Is this possible and any references?
Thanks a lot.
Rather than WinDbg, you can use the Debugging API which is implemented in dbghelp.dll. It's documented on MSDN. That reference documentation is rather dry, but it should give you an idea of the capabilities of the API. For example, MiniDumpReadDumpStream is the gateway to examining dump files.
In addition to the existing answers, WinDBG is a GUI front end for the DbgEng API. You can use this API to write either WinDBG extensions or other standalone applications. The WinDBG SDK ships with samples of both, an example standalone application can be found in the \sdk\samples\dumpstk subdirectory of your WinDBG install.
For more information, I wrote an article about DbgEng to write extensions here:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=559
Most of that will also apply for how you write a standalone application as it mostly focuses on the programming pattern of the DbgEng interface.
here are some links that use dbgeng interfaces to make standalone executables.
a short summary of the process is to
call DebugCreate() to create a client
call QueryInterFace()
and call one of its methods
http://www.woodmann.com/forum/entry.php?252-Dbgeng-based-handles-(PART-2-)
http://www.woodmann.com/forum/entry.php?246-A-Simple-Dbgeng-Based-User-Mode-Debugger
http://www.woodmann.com/forum/entry.php?248-DbgEng-Based-Debugger-(PART2)
http://www.woodmann.com/forum/entry.php?249-DbgEng-Based-Debugger-(PART2-Contd-)
http://www.woodmann.com/forum/entry.php?250-DbgEng-based-Kernel-Debugger
http://www.woodmann.com/forum/entry.php?251-Dbgeng-based-Handles
You could make commands using powershell or to the command line version of WinDbg which is cdb and then parse the output from cdb which you interpret.
This would be similar notion to piping the output from cdb to your app.
There is post about using powershell in this manner: http://rkeithhill.wordpress.com/2006/08/14/minidump-crash-analysis-with-powershell/
It should be straightforward to pump commands to cdb and interpret the output for specific commands.
Python integrated with dbgeng:
pykd.codeplex.com
This project may be use as a demo for such integration
Related
Hi according to this post, unbuffer connects to a command via a pseudo-terminal (pty), which makes the system treat it as an interactive process, therefore not using any stdout buffering.
I would like to use this function on Windows. May I know what is the equivalent of unbuffer program on Windows? Thanks.
I spent some time on this and succeeded. I found this blog during research, and decided to return and provide my solution to save the next guy some time. I'm responding as a guest with a false email so I won't be interacting, but no further information should be required.
On Jul 18 '12 at 19:41 Harry Johnston wrote:
"In principle, if you know how much data to expect, you could use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you."
Thing is, there is already a utility that does this. It's written for a slightly different use, but it can be coxed into providing the desired result. Its intended purpose is to enable a windows console app to interact with a Linux style tty terminal. It does this by running a hidden console and accesses the console buffer directly. If you tried to use it – you'd fail. I got lucky and discovered that there are undocumented switches for this utility which will allow it to provide simple unbuffered output. Without the switches it fails with the error – the output is not a tty – when trying to pipe output.
The utility is called winpty. You can get it here:
https://github.com/rprichard/winpty/releases
The undocumented switches are mentioned here:
https://github.com/rprichard/winpty/issues/103
I’m using the MSYS2 version. You’ll need the msys-2.0.dll to use it.
Simply run:
winpty.exe -Xallow-non-tty -Xplain your_program.exe | receive_unbuffered_output.exe
-Xallow-non-tty , will allow piped output
-Xplain , will remove the added Linux terminal escape codes (or whatever they’re called)
Required files are:
winpty.exe
winpty-agent.exe
winpty.dll
msys-2.0.dll
winpty-debugserver.exe – Not needed
The behaviour you're describing is typical of applications using run-time libraries for I/O. By default, most runtime libraries check to see whether the handle is a character mode device such as a console, and if so, they don't do any buffering. (Ideally the run-time library would treat a pipe in the same way as a console, but it seems that most don't.)
I'm not aware of any sensible way to trick such an application into thinking it is writing to a console when it is actually writing to a pipe.
Addendum: seven years later, Windows finally supports pseudoconsoles. If you are running on Windows 10 v1809 or later, this new API should solve your problem.
On older versions of Windows, if you know how much data to expect, you could in principle use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you.
Similarly, in principle it should presumably be possible to write a device driver equivalent to a Unix pseudo-terminal, one that acts like a pipe but reports itself to be a character-mode device. But writing device drivers requires specific expertise, and they have to be digitally signed, so unless there is an existing product out there this approach isn't likely to be feasible.
Disclaimer: My answer only deals with executables compiled using MSVC.
The buffering policy is coded inside Microsoft C Runtime (CRT) Library. You can learn the details here. This article suggests using console handles and manipulate console buffers to receive unbuffered output.
However, there's an undocumented feature inside Microsoft C Runtime to inherit file handles with some internal flags directly from its parent process using lpReserved2 and cbReserved2 fields of STARTUPINFO structure. You can find the details in the crt source code provided by Microsoft Visual Studio. Or search for something like posfhnd on GitHub.
We can exploit this undocumented feature to provide a pipe handle and specify FOPEN | FDEV flags to the child process, to fool the child process treat that pipe handle the same way as a FILE_TYPE_CHAR handle.
I have a working Python3 script to demonstrate this method.
I am working on a compiler for a small (toy) language that produces 16-bit com-files, which are executable in Windows XP. However, in more modern releases of Windows com-files are executable only with the help of tools such as DosBox. I would like my compiler to produce exe-files that can be executed directly in Windows 10.
As I understand it, the exe-file needs a header that instructs the system of how to execute it. My idea is to simply add the header at the beginning of the com-file to extend it into an exe-file. I wonder if anyone can recommend an appropriate tutorial that describes how exe-files works. More specifically, I am looking for a tutorial of how to build the smallest possible working exe-file.
I also wonder if there is a difference between exe-files for 32-bit or 64-bit Windows?
Best Regards,
Stefan
You can download description exe format here. You need pecoff.docx file.
Also you may look on this old but detailed doc here.
I wonder how to watch new processes that are running or terminated. Can I do it with Windows 7 APIs? How?
I'm using Visual C++ in Windows 7 and don't want to use .Net Framework.
Whilst you can do this using polling (i.e. EnumProcesses), the best way to do it is an event driven approach. And to do that you need to use WMI. This MSDN page gives sample code.
Update Apparently you can use Event Tracing for Windows as an alternative, but I personally know nothing about that.
You may use Process32First and Process32Next from Tool Help library. This MSDN article has an example how to obtain the list of running processes.
An alternative is EnumProcesses function.
I have one Win32 console application which will be independent EXE and I have front-end designed in MFC.
I want to get the results of the Win32 application to be shown on my GUI. I searched a lot and found some techniques:
Named pipe
DDE
Shared memory
Are any of these an appropriate solution to my problem? Does anyone know of any other solution(s) that might be easier than those I mentioned?
If the output of the console exe is machine parsable, you can use CreateProcess() with pipes for standard input and output which you then parse and display in your UI.
You send also message from one application to another, it's quite simple. Look into WM_COPYDATA
http://msdn.microsoft.com/en-us/library/ms649011%28v=vs.85%29.aspx
Is it possible to hook into Windows loading or saving files (no matter how the file is opened like notepad word etc.) to modify the file on the fly?
For example to encode/decode it on the fly?
Would code need administrative permissions to launch?
You probably will have to write a driver. See if you can get a hold of Filemon's source, there is a lot to learn there.
You could also use something like madCodeHook to intercept file read/writes and to install your dll into every process. I've used this technique to record print jobs for billing purposes.
Yes, you need to write an Installable File System driver. The Installable File System Kit from Microsoft contains a couple of sample drivers, including the one used by Filemon. Unfortunately, I do not believe you can access those API's without the IFS Kit.
avoid madCodeHook (not profesdional)
use standard api hooking mechanisms (Richter and Microsoft D mainly)