Reading Monitoring certain system calls done by a process in Windows, I'm wondering about a Windows equivalent to the ptrace system call or a programmatical workaround.
You can use ETW to trace system calls. When starting the trace, in EVENT_TRACE_PROPERTIES, you can add EVENT_TRACE_FLAG_SYSTEMCALL flag to EnableFlags. This enables SysCallEnter and SysCallLeave events, as described here.
Related
Is there something like seccomp that works on Windows?
It should limit all syscalls to some very limited set, like only reading and writing to already opened files.
The one described as sandbox for Chromium does not look like Seccomp, as it is based on usual file permissions and Windows security objects, not on limiting access to syscalls.
No, there is nothing like seccomp that works on Windows. The closest there is are traditional permissions which disable certain privileged syscalls. But currently, there is no way to whitelist or blacklist entire arbitrary syscalls, or syscall arguments on Windows.
Since Windows 8 you can block all calls from win32k.sys with DisallowWin32kSystemCalls flag in PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY structure.
You can't gradually control system calls as it in seccomp, but this is still an interesting feature.
I need to capture the DeviceIoControl() system calls of an application. On linux, strace can be used to analyze all ioctl calls. Is there any similar functionality on windows?
MSDN website recommends a program called "Process Monitor" to analyze the real-time activities of executables. However, "Process Monitor" does not show anything about DeviceIoControl calls.
Have you tried OSR's IRPTracker?
IrpTracker allows you to monitor all I/O request packets (IRPs) on a system without the use of any filter drivers and with no references to any device objects, leaving the PnP system entirely undisturbed. In addition to being able to see the path the IRP takes down the driver stack and its ultimate completion status, a detailed view is available that allows you to see the entire contents of static portion of the IRP and an interpreted view of the current and previous stack locations.
To capture the DeviceIoControl() function you can use an API hook. My company provides Deviare, a hook engine with a high level interface. You don't need to know a lot about hooking it can be used freely (just display a dialog saying unregistered version). It includes a hook console with source code.
Recently discovered Rohitab's API Monitor
It hasn't been updated for 2 years, but it does work on my Win7 x64. It has very good API filtering capabilities.
The Dr. Memory (http://drmemory.org) tool comes with a system call tracing tool called drstrace that lists all system calls made by a target application, including NtDeviceIoControlFile, along with their arguments: http://drmemory.org/strace_for_windows.html
Asked by an Interviewer:
How can we find if an application has become non responsive due to a deadlock or due to wait on some IO?
Can anybody comment any general way of doing this, or if various provides some specific ways of doing this?
This is an OS related thing I believe so I am not tagging any language here.
EDIT: I would like to know about the techniques and the APIs as well to do this. So that i can run a monitoring program if i wish.
On linux I would use sar -u 1. If the %iowait column is high, then the application is probably waiting for IO
On Windows you can attach WinDbg and then execute !analyze -v -hang which will work out which thread is waiting on I/O. (The only time I used this I got lucky and it was an open call which was waiting, so I got to find out the file name very quickly.)
The answer is there are many possible design as solutions.
If in your application, u use open() with lockf() or flock() to lock the resource. So the next time another process (or the same process) attempt to flock() the same file again it will be blocked.
If u open a file with LOCK_NB (see "man -s 2 flock in Ubuntu) non-blocking locks, and then returned with EWOULDBLOCK error, then u can deduce that the file is locked.
To identify all the locked files in the OS, one way is to do a "lsof" to see all the opened files, and from the filename and using fcntl() u can identify the types of locks held.
Many possible alternative designs: eg, for Oracle database there is a concept called waiter list to list all the waiters waiting on the existing locked records. Because of this sophisticated design, automatic deadlock detection is also possible.
http://www.dba-oracle.com/t_deadlock.htm
Other techniques are described in general OS courses:
http://lovingod.host.sk/tanenbaum/Recovery-from-Deadlock.html
On Linux you can attach gdb to a running process. It'll stop the process at the point where is is running, with bt you'll get the back-trace. You can also get the thread info of all running threads, switch between them and look at the back-trace of each using info threads; thread N; bt.
Another very useful tool under Linux is strace which traces system calls, you can also attach this to running processes. The -c option shows you profiling information of the system calls done by the program.
I have intensive processing that I need to perform in a device driver, at DISPATCH_LEVEL or lower IRQL.
How do I create a kernel-thread?
What IRQL does it run at? Can I control this?
How is it scheduled? Because I am thinking from a user-mode perspective here, what priority does it run at?
What kernel functions can I use to provide locking / synchronization?
you can create system thread with this As you can see one of its parameters is a start routine which can hold custom code - in it you can use KeRaiseIrql and KeLowerIrql. By default threads will run in PASSIVE_LEVEL. "Locks, Deadlocks, and Synchronization" is a very helpful paper regarding synchronization in kernel on windows and everyone who has to do some tinkering with the windows kernel should read or at least skim it
I am looking for different ways to pause and resume programmatically a particular process via its process ID under Windows XP.
Process suspend/resume tool does it with SuspendThread / ResumeThread but warns about multi-threaded programs and deadlock problems.
PsSuspend looks okay, but I wonder if it does anything special about deadlocks or uses another method?
Prefered languages : C++ / Python
If you "debug the debugger" (for instance, using logger.exe to trace all API calls made by windbg.exe), it appears that the debugger uses SuspendThread()/ResumeThread() to suspend all of the threads in the process being debugged.
PsSuspend may use a different way of suspending processes (I'm not sure), but it is still possible to hang other processes: if the process you're suspending is holding a shared synchronization object that is needed by another process, you may block that other process from making any progress. If both programs are well-written, they should recover when you resume the one that you suspended, but not all programs are well-written. And if this causes your program that is doing the suspending to hang, then you have a deadlock.
I'm not sure if this does the job, but with ProcessExplorer from MS Systernals you can suspend a process.
It's been said here: https://superuser.com/a/155263 and I found it there too.
read here and you also have psutil for python that you can use it like that:
>>> import psutil
>>> pid = 7012
>>> p = psutil.Process(pid)
>>> p.suspend()
>>> p.resume()
I tested http://www.codeproject.com/KB/threads/pausep.aspx on few softwares:
it works fine.
PsSuspend and Pausep are two valid options.
So, after I found about UniversalPauseButton, Googling for this ("windows SIGSTOP"), getting this question as the first search result (thanks Ilia K. your comment did its job), and reading the answers, I went back to checkout the code.
Apparently, it uses undocumented NT kernel and Win32 APIs _NtSuspendProcess, _NtResumeProcess and _HungWindowFromGhostWindow.
PsSuspend, the utility you mentioned and linked to probably uses these APIs, I couldn't verify this, the source code isn't supplied, only executables and a EULA, you can probably figure that out by disassembling the binary but it's against the EULA.
so, to answer your specific question, checkout UniversalPauseButton's main.cpp, basically you call _NtSuspendProcess(ProcessHandle) and _NtResumeProcess(ProcessHandle), ProcessHandle being the handle of the process you want to pause or resume.
I think there is a good reason why there is no SuspendProcess() function in Windows. Having such a function opens the door for an unstable system. You shall not suspend a process unless you created that process yourself.
If you wrote that process yourself, you could use an event (see ::SetEvent() etc. in MSDN) or another kind of messaging to trigger a pause command in the process.