WinDBG - how to set all exception to be passed into app? - windbg

How can I set all exceptions behavior to pass to application and not appear in debugger?
I'm using IDA Pro 6.6 and WinDbg.

It's a bit awkward to do that for all exception types at once
.foreach(exc {sx}) {.catch{sxd ${exc}}}
What it does:
{sx}: list all exception types (and current settings, which you actually don't want)
exc: assign a variable
.foreach(...) {...}: cut it into pieces of single words and execute a command
sxd ${exc}: disable whatever is in variable exc
.catch{...}: ignore all the error messages which come from the settings information
The advantage of the above approach is that it is WinDbg version independent. If new exception codes are introduced, it will still work.
Processing of unwanted text can be avoided with PyKd. Save the following script into a file sdx.py and run !py sxd.py:
from pykd import *
sx = dbgCommand("sx")
for s in sx.splitlines():
ex = s[:4]
if not ex=="" or ex.isspace():
print("sxd "+ex)
dbgCommand("sxd "+ex)
Another option is processing all the exceptions manually:
.foreach(exc {.echo "ct et cpr epr ld ud ser ibp iml out av asrt aph bpe bpec eh clr clrn cce cc dm dbce gp ii ip dz iov ch hc lsq isc 3c svh sse ssec sbo sov vs vcpp wkd rto rtt wob wos *"}) {.catch{sxd ${exc}}}
However, if there are new exception codes in WinDbg, you have to add them to the .echo command.

In Windbg the sx family of commands is used to control how
exceptions should be handled.
For passing an exception directly to the application, use the sxd command which disable a specific exception.
(Actually disable mean ignore first chance exception)
To my knowledge, you must use sxd on all specific exceptions,
because sxd * means all exceptions that are not otherwise explicitly named.
Use the sx command to see the available exceptions and current settings. And use sxd on all you want to disable.
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
cpr - Create process - ignore
<cut>
av - Access violation - break - not handled
0:000> sxd av
0:000> sx
ct - Create thread - ignore
et - Exit thread - ignore
<cut>
av - Access violation - second-chance break - not handled
The output is in my opinion a bit difficult to interpret; the av (access violation) will now not be handled by the debugger in any visible way.
The “Controlling Exceptions and Events” section in the help explains
the first chance and second-chance concept.

You can optionally control this from the WinDbg GUI 'Debug>Event Filters...' this will open a dialog box like so:
Here you can set how WinDbg handles each exception type and whether they should be enabled, disabled, outputted to the WinDbg console output or ignored and then on the event firing whether WinDbg or your app should handle it.
So in your case you can select 'Ignore' and 'Not Handled' there a MSDN page that explains a little more: https://msdn.microsoft.com/en-us/library/windows/hardware/ff541752(v=vs.85).aspx

Related

arm64 ptrace SINGLESTEP: are the steps described in this paper correct?

I was reading the paper Hiding in the Shadows: Empowering ARM for Stealthy Virtual Machine Introspection and I was wondering whether the steps they are described in paragraph "2.3 Debug Exceptions" were correct or not:
AArch64 allows to generate Software Step exceptions by setting the SS
bit of the Monitor Debug System Control MDSCR_EL1 and Saved Program
Status Register SPSR of the target exception level. For instance, to
single-step a hit breakpoint in EL1 the monitor must set the
MDSCR_EL1.SS and SPSR_EL1.SS bits. After returning to the trapped
instruction, the SPSR will be written to the process state PSTATE
register in EL1. Consequently, the CPU executes the next instruction
and generates a Software Step exception.
I have tried to understand how single-stepping happens in freeBSD, and I am noticing a mismatch.
I am basing the following lines of code to the release 12.3.0 of freeBSD (4 December 2021), commit: 70cb68e7a00ac0310a2d0ca428c1d5018e6d39e1. I chose to base this question on freeBSD because, in my opinion, following its code is easier than Linux, but the same principles shall be common to both families.
According to my understanding, this is what happens in freeBSD:
1- Ptrace single step is invoked, arriving in the architecture-independent code proc_sstep(), in sys_process.c:
int proc_sstep(struct thread *td)
{
PROC_ACTION(ptrace_single_step(td));
}
2- Architecture-dependent code ptrace_single_step()is called, in arm64/ptrace_machdep.c:
int ptrace_single_step(struct thread *td)
{
td->td_frame->tf_spsr |= PSR_SS;
td->td_pcb->pcb_flags |= PCB_SINGLE_STEP;
return (0);
}
Here single step bit (number 21) is set in the "Process State" of the tracee (tracee = thread that is traced) and a flag is set.
3- After a while, the traced task will be selected for scheduling. In cpu_throw() of swtch.S (where the new thread takes place), the flags of the new thread are checked, to see if it must single step:
/* If we are single stepping, enable it */
ldr w5, [x4, #PCB_FLAGS]
set_step_flag w5, x6
4- set_step_flag macro in defined in the same swtch.S:
.macro set_step_flag pcbflags, tmp
tbz \pcbflags, #PCB_SINGLE_STEP_SHIFT, 999f
mrs \tmp, mdscr_el1
orr \tmp, \tmp, #1
msr mdscr_el1, \tmp
isb
999:
.endm
Here, if the single-step flag is set, it sets the single step bit of register MDSCR_EL1 (bit in position 0).
4- To the best of my understanding, the combination of single step bit on SPSR_EL1 of the "Pstate" + single step bit on MDSCRL_EL1 implies that the tracee execute 1 instruction and it traps.
5- Trap is recognized as a EXCP_SOFTSTP_EL0 and it is handled in do_el0_sync() function of trap.c:
case EXCP_SOFTSTP_EL0:
td->td_frame->tf_spsr &= ~PSR_SS;
td->td_pcb->pcb_flags &= ~PCB_SINGLE_STEP;
WRITE_SPECIALREG(mdscr_el1,
READ_SPECIALREG(mdscr_el1) & ~DBG_MDSCR_SS);
call_trapsignal(td, SIGTRAP, TRAP_TRACE,
(void *)frame->tf_elr, exception);
userret(td, frame);
break;
Here, all the flags are reset and the traced thread receives a SIGTRAP (sent by itself, I think). Being traced, it will stop. And the tracer, at this point, can return from a possible waitpid().
What I could observe differs from the paper explanation. Can you check and correct the steps that I listed, please ?

Can I disable the "Unable to read dynamic function table entry" message in WinDbg?

I'm working with a program that generates a lot of code at runtime, and seems not to produce any unwind data for it. (I don't have source code for this program; I'm writing a plugin for it.)
When the program hangs, I break into it with WinDbg, and try to get a stack trace for all threads with ~* k. As well as the stack traces, I also get pages and pages (and pages, and more) of messages along the line of
Unable to read dynamic function table entry at 00000000`2450b580
This takes a long time to print - over a minute - and it overflows the scroll buffer, so I lose most of the output.
I've worked around this for now by hex-editing the DLL that contains this message, but... seriously. Is there an official way of getting rid of this message?
I'm prepared for a crappy stack trace from the problem thread(s).
Note that this is a security feature, so disable it at your own risk. There are two options:
If you know which module is causing this, you can add the full path to the register: HKLM\Software\Microsoft\Windows NT\CurrentVersion\KnownFunctionTableDlls registry key
You can disable it with .settings set EngineInitialization.VerifyFunctionTableCallbacks=false
The second option only disables it for the current session. If you want to make it permanent, you can follow it with .settings save.
if you are running the latest versions of windbg
you can try setting the Engine Initialization Settings
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks : true
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks = false
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks = false : false
0:000> dx Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks
Debugger.Settings.EngineInitialization.VerifyFunctionTableCallbacks : false

c++ amp matrixmultiplication accelerator_view_removed at memory location

I am playing with the matrixmultiplication project downloadable from the bottom of the site:
http://blogs.msdn.com/b/nativeconcurrency/archive/2011/11/02/matrix-multiplication-sample.aspx
When I change the values of M, N, W from 256 to 4096, an unhandled exception is thrown:
Unhandled exception at 0x7630C42D in MatrixMultiplication.exe: Microsoft C++ exception: Concurrency::accelerator_view_removed at memory location 0x001CE2F0.
The console output is:
Using device: NVIDIA GeForce GT 640M
MatrixDiemnsion C(4096x4096) = A(4096x4096) * B(4096x4096)
CPU(single core) exec completed.
AMP Simple
The next statement to be executed is leaving the function mxm_amp_simple.
I am using VS2013 Ultimate on Windows 7 Professional N.
Why does this occur and how to prevent this from happening?
EDIT: I have found that the greatest value for M,N,W with which AMP Simple does not lead to a breakpoint being hit is 2800 (M=2800, N=2800, W=2800).
AMP Tiled on the other hand sometimes leads to a breakpoint, and in other cases executes correctly for M,N,W equal to 4096.
The exception is accompanied by a system error message:
"Display driver stopped responding and has recovered. Display driver NVIDIA Windows Kernel Mode Driver, Version 331.65 stopped responding and has successfully recovered."
In case someone else needs this.
This issue is most likely caused by Timeout Detection and Recovery (TDR). If kernel runs for more then 2 seconds windows will kill it and throw Concurrency::accelerator_view_removed exception. The easiest way to check this is to wrap code in try / catch bock. E.g.
try {
av_c.synchronize();
} catch (const Concurrency::accelerator_view_removed& e) {
printf("%s\n", e.what());
}
Microsoft has a blog post with more information, including pointers to instructions how to disable it.

Ignore certain exceptions when using Xcode's All Exceptions breakpoint

I have an All Exceptions breakpoint configured in Xcode:
Sometimes Xcode will stop on a line like:
[managedObjectContext save:&error];
with the following backtrace:
but the program continues on as if nothing happened if you click Continue.
How can I ignore these "normal" exceptions, but still have the debugger stop on exceptions in my own code?
(I understand that this happens because Core Data internally throws and catches exceptions, and that Xcode is simply honoring my request to pause the program whenever an exception is thrown. However, I want to ignore these so I can get back to debugging my own code!)
Moderators: this is similar to "Xcode 4 exception breakpoint filtering", but I think that question takes too long to get around to the point and doesn't have any useful answers. Can they be linked?
For Core Data exceptions, what I typically do is remove the "All Exceptions" breakpoint from Xcode and instead:
Add a Symbolic Breakpoint on objc_exception_throw
Set a Condition on the Breakpoint to (BOOL)(! (BOOL)[[(NSException *)$x0 className] hasPrefix:#"_NSCoreData"])
The configured breakpoint should look something like this:
This will ignore any private Core Data exceptions (as determined by the class name being prefixed by _NSCoreData) that are used for control flow. Note that the appropriate register is going to be dependent on the target device / simulator that you are running in. Take a look at this table for reference.
Note that this technique can be adapted easily to other conditionals. The tricky part was in crafting the BOOL and NSException casts to get lldb happy with the condition.
I wrote an lldb script that lets you selectively ignore Objective-C exceptions with a much simpler syntax, and it handles both OS X, iOS Simulator, and both 32bit and 64bit ARM.
Installation
Put this script in ~/Library/lldb/ignore_specified_objc_exceptions.py or somewhere useful.
import lldb
import re
import shlex
# This script allows Xcode to selectively ignore Obj-C exceptions
# based on any selector on the NSException instance
def getRegister(target):
if target.triple.startswith('x86_64'):
return "rdi"
elif target.triple.startswith('i386'):
return "eax"
elif target.triple.startswith('arm64'):
return "x0"
else:
return "r0"
def callMethodOnException(frame, register, method):
return frame.EvaluateExpression("(NSString *)[(NSException *)${0} {1}]".format(register, method)).GetObjectDescription()
def filterException(debugger, user_input, result, unused):
target = debugger.GetSelectedTarget()
frame = target.GetProcess().GetSelectedThread().GetFrameAtIndex(0)
if frame.symbol.name != 'objc_exception_throw':
# We can't handle anything except objc_exception_throw
return None
filters = shlex.split(user_input)
register = getRegister(target)
for filter in filters:
method, regexp_str = filter.split(":", 1)
value = callMethodOnException(frame, register, method)
if value is None:
output = "Unable to grab exception from register {0} with method {1}; skipping...".format(register, method)
result.PutCString(output)
result.flush()
continue
regexp = re.compile(regexp_str)
if regexp.match(value):
output = "Skipping exception because exception's {0} ({1}) matches {2}".format(method, value, regexp_str)
result.PutCString(output)
result.flush()
# If we tell the debugger to continue before this script finishes,
# Xcode gets into a weird state where it won't refuse to quit LLDB,
# so we set async so the script terminates and hands control back to Xcode
debugger.SetAsync(True)
debugger.HandleCommand("continue")
return None
return None
def __lldb_init_module(debugger, unused):
debugger.HandleCommand('command script add --function ignore_specified_objc_exceptions.filterException ignore_specified_objc_exceptions')
Add the following to ~/.lldbinit:
command script import ~/Library/lldb/ignore_specified_objc_exceptions.py
replacing ~/Library/lldb/ignore_specified_objc_exceptions.py with the correct path if you saved it somewhere else.
Usage
In Xcode, add a breakpoint to catch all Objective-C exceptions
Edit the breakpoint and add a Debugger Command with the following command:
ignore_specified_objc_exceptions name:NSAccessibilityException className:NSSomeException
This will ignore exceptions where NSException -name matches NSAccessibilityException OR -className matches NSSomeException
It should look something like this:
In your case, you would use ignore_specified_objc_exceptions className:_NSCoreData
See http://chen.do/blog/2013/09/30/selectively-ignoring-objective-c-exceptions-in-xcode/ for the script and more details.
Here is an alternative quick answer for when you have a block of code e.g. a 3rd part library that throws multiple exceptions that you want to ignore:
Set two breakpoints, one before and one after the exception throwing block of code you want to ignore.
Run the program, until it stops at an exception, and type 'breakpoint list' into the debugger console, and find the number of the 'all exceptions' break point, it should look like this:
2: names = {'objc_exception_throw', '__cxa_throw'}, locations = 2
Options: disabled
2.1: where = libobjc.A.dylibobjc_exception_throw, address = 0x00007fff8f8da6b3, unresolved, hit count = 0
2.2: where = libc++abi.dylib__cxa_throw, address = 0x00007fff8d19fab7, unresolved, hit count = 0
This means it is breakpoint 2. Now in xcode, edit the first breakpoint (before the exception throwing code) and change the action to 'debugger command' and type in 'breakpoint disable 2' (and set 'automatically continue...' checkbox ).
Do the same for the break point after the offending line and have the command 'breakpoint enable 2'.
The all breakpoints exception will now turn on and off so it's only active when you need it.

How do I find the handle owner from a hang dump using windbg?

How do I find out which thread is the owner of my Event handle in windbg:
I'm running
!handle 00003aec f
and get
Handle 00003aec
Type Event
Attributes 0
GrantedAccess 0x1f0003:
Delete,ReadControl,WriteDac,WriteOwner,Synch
QueryState,ModifyState
HandleCount 2
PointerCount 4
Name <none>
No object specific information available
back, and as there is no Name I haven't figured out how to get the owner out to prove which thread my thread is waiting on
[Edit] I must work against a dump as the original process needs to be restarted on the users machine, so can't debug a live session
The best discussion on the subject I've found so far is on this blog, but unfortunately we end up using different lock methods (I end up using WaitForMultipleObjectsEx and the description is for WaitForSingleObject), and he seems to have access to a live process
the stacktrace of my thread (the one that is blocked on something and where I'm looking for the current owner) is:
0:045> k9
ChildEBP RetAddr
1130e050 7c90e9ab ntdll!KiFastSystemCallRet
1130e054 7c8094e2 ntdll!ZwWaitForMultipleObjects+0xc
1130e0f0 79ed98fd kernel32!WaitForMultipleObjectsEx+0x12c
1130e158 79ed9889 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
1130e178 79ed9808 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
1130e1fc 79ed96c4 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
1130e24c 79ed9a62 mscorwks!Thread::DoAppropriateWait+0x40
1130e2a8 79e78944 mscorwks!CLREvent::WaitEx+0xf7
1130e2bc 7a162d84 mscorwks!CLREvent::Wait+0x17
1130e33c 7a02fd94 mscorwks!CRWLock::RWWaitForSingleObject+0x6d
1130e364 79ebd3af mscorwks!CRWLock::StaticAcquireWriterLock+0x12e
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Looking at the callstack it appears that the stack in question is using a ReaderWriterLock locking mechanism.
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Change to thread 9 and using sos.dll run !dso to dump out the managed ReaderWriterLock object. Then run !do on that the ReaderWriterLock object. I believe that there is an owning thread field that you can query. I will test it and see.
The old school way to determine this is to run ~*e !clrstack and examine all of the managed threads that are waiting on a readerwriter lock and then see if you can find the thread that has entered the same function but passed through the lock (ie. different offset)
Thanks,
Aaron
Note: Not sure if there is a way to link posts but this one is very similar to
How do I find the lockholder (reader) of my ReaderWriterLock in windbg
Use the !htrace command to get the thread ID. You must first, possibly at the start of the program, enable the collection of traces with !htrace -enable.
0:001> !htrace 00003aec
--------------------------------------
Handle = 0x00003aec - OPEN
Thread ID = 0x00000b48, Process ID = 0x000011e8
...
The above output is fictional, it will be different for your system. But it will give you the piece of information you need - the thread ID (0x00000b48 in my example).
I must work against a dump as the
original process needs to be restarted
on the users machine, so can't debug a
live session.
I am not 100% sure but I think this will work:
Attach to the process and run !htrace -enable
Detach from the process with qd. The executable will continue.
You can now take a dump file and use the above command - I think you will have the described results.
You can dig that out of a kernel dump.
Now, as far as kernel debugging goes, livekd from sysinternals should be sufficient but unfortunately it is only usable on a running system.
There's also a kernel mode memory acquisition tool which might be of use to take a dump with (in windbg's stead) for later inspection.
Otherwise, enabling handle tracing (!htrace -enable) and (if code unique to particular thread), the handle ownership could be concluded from a stack trace.
Here's the definitive answer I found. Never tried myself. You'll need live debugging to determine the owner though. But it's pretty quick.
http://weblogs.thinktecture.com/ingo/2006/08/who-is-blocking-that-mutex---fun-with-windbg-cdb-and-kd.html