How Can I Find the Code Executed at the Specified Offset in ucrtbase.dll?

See this comment Windows c++ service faulting on ucrtbase.dll when starting

(Duplicated from the Post)

ucrtbase + 7350e is the int 0x29 instruction in the CRT's abort function. This is the __fastfail intrinsic for a KERNEL_SECURITY_CHECK_FAILURE with the code FAST_FAIL_FATAL_APP_EXIT (7). The interrupt gets serviced by KiRaiseSecurityCheckFailure, which raises STATUS_STACK_BUFFER_OVERRUN (0xC0000409)

The information provided there is useful from a debugging perspective (well academically useful, its not the runtime's fault that an overflow has occurred, he's just the unlucky guy to report it), how was this user able to determine this?

I realize that some of the code to the C Language Runtime is provided but how do you transition from the offset to the source file?

I have a similar issue I am trying to track down here:

Fault Module Name:  ucrtbase.dll
Fault Module Version:   10.0.14393.2097
Fault Module Timestamp: 5a820a13
Exception Offset:   000000000006eabe
Exception Code: c0000409

I am looking for the code at ucrtbase + 6eade

It is possible to know the line where an application faulted even if it was not running under debugger or memory dump is not available. It won’t probably tell you why it failed, but it will give you at least a point where to start investigating.

After the application failed, look at the Windows Event Logs for an entry like this:

"Faulting application yourapp.exe, version 1.0.0.0, time stamp 0x49e0238, faulting module yourmodule.dll, version 1.1.0.0, time stamp 0x09ec5a57, exception code 0xc0000005, fault offset 0x000000000051000e, process id 0x00, application start time 0x00."

Load the module that faulted using windbg.exe -z c:\yourmodule.dll (make sure you have symbols!) List the modules loaded (yourmodule.dll in this case)

0:000> lm
start             end                 module name
00000000`00300000 00000000`00425000   yourmodule    (private pdb symbols)  c:\yourmodule.pdb

Find the line where it crashed by adding the 'fault offset' reported in the event viewer to the 'start' address of your module

0:000> ln 300000+5100e
c:\sources\myclass.cpp(130)+0x14

If your symbols don’t match exactly the module that is in production, you can try in windbg the command ‘.symopt +0x40’; it will make it less restrictive.