Re: windbg digest: October 21, 2017

WINDBG
1

Hi Misc.usage,

“kv” is a souped up “dps @esp” with the space between function addresses
removed by WinDBG looking a FPO information from the PDB.
When FPO info not available, WinDBG will do best it can and sometimes, it
gets it right.

If memory serves me, MoveSmall is a label within strcpy asm code that will
copy the heading or trailing bytes that are not 8 byte aligned.
The 8 byte aligned ones within the string are copied 8 bytes at a time.

Look at the code being executed and if there are string copy/string move
being done or even a non-string like a “int arrayOfInts[100] = {0};”, it
makes sense that MoveSmall would be there. The compiler uses it to
initialize that array full of zeros.

A lot of times, the problem is that the count of characters to be copied
has been overwritten but strcpy will obey, overwriting lots of stuff, even
crashing the process depending on the target address of the copy (e.g. if
it happens to be a local variable on the stack, your process is toast).

Happy debugging,
Osiris

On Sun, Oct 22, 2017 at 12:00 AM Kernel Debugging Interest List digest <
xxxxx@lists.osr.com> wrote:

WINDBG Digest for Saturday, October 21, 2017.

  1. Weird looking entry at top of stack

Subject: Weird looking entry at top of stack
From: xxxxx@gmail.com
Date: Sat, 21 Oct 2017 11:16:48 -0400 (EDT)
X-Message-Number: 1

I am staring at a crash dump that is running into an access violation
exception while executing a mov instruction in VCRUNTIME140!MoveSmall
(which is part of memcpy.asm code.)

My question is MoveSmall doesn’t even look like a *function*. Its a jump
label where control can be transferred if necessary. I am unable to
reconcile why it shows up on ‘kv’. The previous function that supposedly
transferred control there is not even meant to call anything in
VCRUNTIME140.

Sorry I am unable to post anything of value here because of propreitory
reasons. If the question cannot be answered as is, please feel free to let
me know.

END OF DIGEST

You are currently subscribed to windbg as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

2

Thank you Osiris. MoveSmall seems to be a label in memcpy.asm. Nevertheless I will take a closer look and see if buffer is being overrun somewhere.

3

"xxxxx@gmail.com windbg"@lists.osr.com wrote:

Thank you Osiris. MoveSmall seems to be a label in memcpy.asm. Nevertheless I will take a closer look and see if buffer is being overrun somewhere.

The source code for the runtime library ships with the product. 
MoveSmall is a table of function pointers for handlers of moves up to 16
bytes.  It is not executable code.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Hello Tim – That MoveSmall is not executable code seems obvious in hindsight :slight_smile: I got misled by how the debugger was interpreting the symbol at that address. One other question, when I do this:

0:000> x VCRUNTIME140!MoveSmall
0000xxxx`xxxxxxxx VCRUNTIME140!MoveSmall = 0xc4d0

I am not sure how to interpret that output. What does that 0xc4d0 mean?

5

"xxxxx@gmail.com windbg"@lists.osr.com wrote:

Hello Tim – That MoveSmall is not executable code seems obvious in hindsight :slight_smile: I got misled by how the debugger was interpreting the symbol at that address. One other question, when I do this:

0:000> x VCRUNTIME140!MoveSmall
0000xxxx`xxxxxxxx VCRUNTIME140!MoveSmall = 0xc4d0

I am not sure how to interpret that output. What does that 0xc4d0 mean?

It’s just trying to show you the contents of the variable.  Again, you
can look up this source code in your Visual Studio directory, in
vc\crt\src\amd64\memcpy.asm.  MoveSmall is a table of offsets to
routines that handle moves of from 0 to 16 bytes.  The first entry
happens to be the degenerate case of a 0-byte move, so this says the
MoveSmall0 function is located 0xC4D0 bytes from the start of the module.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.