16

I'm currently testing an application that my company wrote. One of the scenarios was to see what happens to the system state if that application was to crash. Is there an application out there that could force crash my application? I'd rather not write a crash into the code itself (ie. null pointer dereference). Using the task manager to kill the process doesn't yield the same results.

4
  • Using DLL Injection might be a viable route to achive this, I don't know of any app that already would handle this however. Commented Nov 26, 2010 at 11:41
  • Can't you put a simple exit() in the middle of your cod ? Or isn't that considered as "crashing" ? Commented Nov 26, 2010 at 11:42
  • What do you mean by system state? Generally when a process crashes, the system will clean up all the resources used. However this might not extend to things like database handles. How will you examine the system state? Commented Nov 26, 2010 at 11:44
  • Crash is a result, you should precise the cause. Commented Nov 26, 2010 at 12:48

11 Answers 11

18

On Windows you can attach WinDbg to a process, corrupt some register or memory and detach. For instance you can set instruction pointer to 0 for some active application thread.

windbg -pn notepad.exe 

Right after attach, current thread is set to debug thread, so you need to change to app thread to make it crash with RIP register update

0:008> ~0s 0:000> rip=0 0:000> qd 
Sign up to request clarification or add additional context in comments.

Comments

12

Assuming Windows, see Application Verifier.

It can do fault injection (Low Resource Simulation) that makes various API calls fail, at configurable rates. E.g. Heap allocations, Virtual Alloc, WaitForXxx, Registry APIs, Filesystem APIs, and more.

You can even specify a grace period (in milliseconds) when no faults will be injected during startup.

1 Comment

Nice, I didn't know about this tool. Looks like it could be very useful!
6

You can use the winapiexec tool for that:

winapiexec64.exe CreateRemoteThread ( OpenProcess 0x1F0FFF 0 1234 ) 0 0 0xDEAD 0 0 0

Replace 1234 with the process id and run the command, the process will crash.

Comments

3

The best way is to call RaiseException API from windows.h

RaiseException(0x0000DEAD,0,0,0); 

Or you can do a runtime linking to KeBugCheckEx() from ntoskrnl.exe and call it in your code.

Example:

#include <windows.h> #include <iostream> using namespace std; int main() { HINSTANCE h = LoadLibrary("ntoskrnl.exe"); cout<<h<<endl; void* a; a = (void*) GetProcAddress(h,"KeBugCheckEx"); int(*KeBugCheckEx)(ULONG,ULONG_PTR,ULONG_PTR,ULONG_PTR,ULONG_PTR); KeBugCheckEx = (int(*)(ULONG,ULONG_PTR,ULONG_PTR,ULONG_PTR,ULONG_PTR))a; cout << a; KeBugCheckEx(0,0,0,0,0); //crash in module ntoskrnl.exe means that call success! } 

2 Comments

RaiseException is a reasonable answer to a slightly different question: How should a Windows application crash itself if it detects a problem? Though the flags argument should probably be EXCEPTION_NONCONTINUABLE rather than 0. KeBugCheckEx crashes the operating system, which is overkill unless you're calling it from kernel mode and crashing the system is necessary to prevent corruption.
For the RaiseException solution, it's probably best to use the exception code STATUS_FAIL_FAST_EXCEPTION (0xC0000409). If you want to use your own custom exception codes, make sure you set bit 29 (indicated a user-defined code) and leave bit 28 clear (because it's reserved by the system). In other words, your exception codes should probably start with 0xE in the high nybble, as in 0xE000DEAD.
2

You haven't stated which OS you're running on but, if it's Linux (or another UNIX-like system), you can just kill -9 your process. This signal can't be caught and will result in the rug being pulled out from under your process pretty quickly.

If you're not on a UNIX-like system, I can't help you, sorry, but you may find some useful information here (look for "taskkill").

Comments

1

If the system runs on UNIX/Linux you can send it a signal: SIGQUIT should produce a core-dump, you can also send it SIGSEGV if you want to test it getting a "segmentation fault". Those are signal 3 and 11 respectively.

If the system is Windows I do not know a way to raise a signal in a different application but if you can modify the application to handle a specific Windows message number that will call raise() you can emulate that. raise() causes the signal to be raised without actually having to write code that performs an illegal action. You can then post a message to the application which will have the handler that raises this signal.

1 Comment

See my post about RaiseException. Open its process, get some raw function pointer, or just corrupt its heap :)
1

You could override the global new operator. Then, you can use a counter and at a specific value you perform a null pointer dereference to force your application to crash. By simply changing the value of when to perform the dereference you can easily vary the time of crash.

Comments

0

Where is this "system state" defined? If this were unix, you could send a signal 9 to the process...

If you really needed to, you could share all the application memory with another process (or thread), and have that thread randomly write random data some unfortunate memory location - I think NASA did this for some of their space projects, but I really couldn't give a reference.

The real question is why you want to do this - what are you /really/ testing?

If this is, for example, some program that controls some medical service that prescribes drugs... Unit test that service instead, analyse the API, and look for flaws.

Comments

0

Make a bufferoverflow yourself.

#include <string.h> void doSomething(char *Overflow) { char Buffer[1]; strcpy(Buffer, Overflow); } int main() { doSomething("Muhaha"); } 

And your program will crash

1 Comment

Sadly not in a reliable way it won't -- this is just undefined behaviour, it may not always result in a guaranteed crash.
0

An alternative would be to run the application in a good debugger, set a breakpoint to a particular line of code, and viola, your application has "crashed". Now, this might not cause all your threads to stop running, depending on the debugger being used. Alternatively, you could run the application in the debugger, and simply "stop" the application after a time.

This doesn't neccessarily result in a crash with the kernel killing the application (and possibly dumping core) but it would probably do what you want regardless.

Comments

-1

Call abort() function from your code. Other programs can't reliably "crash" your program - they have their own process context which is isolated from your program's context. You could use something like TerminateProcess() in Windows API or another platform-specific function but that would be more or less the same as using Task Manager.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.