I have a xamarin ios app that has been functioning well in debug mode, But after I bundle and sign the app for the store, and install it in testflight, the app crashes at startup.
So, what I did was run the code in VS in release mode, with dev provisioning profiles.
I discovered appcenter crashed the app at runtime.
I've tried a lot of things, I saw this doc stating I should update my xamarin iOS components to 10.4.0.128 or later,
Since my app was targeting version 10 of iOS, I targeted version 11 in the info.plist.
But it still didn't work. Could someone help ? please
Here is the error I got from appcenter:
error: Failed to load AOT module 'Microsoft.AppCenter.iOS.Bindings' while running in aot-
only mode: doesn't match assembly.
Failed to load AOT module 'Microsoft.AppCenter.iOS.Bindings' while
running in aot-only mode: doesn't match assembly
=================================================================
Native Crash Reporting
=================================================================
Got a abrt while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
Native stacktrace:
=================================================================
0x10811def0 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_dump_native_crash_info
0x10811415c - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_handle_native_crash
0x10811d43c - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_runtime_posix_install_handlers
0x1f071b298 - /usr/lib/system/libsystem_platform.dylib : <redacted>
0x1f0720b50 - /usr/lib/system/libsystem_pthread.dylib : pthread_kill
0x1ae09fb74 - /usr/lib/system/libsystem_c.dylib : abort
0x10795f770 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : xamarin_find_protocol_wrapper_type
0x1080eae70 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : monoeg_g_logv
0x1080eaec0 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : monoeg_g_log
0x1080f3b58 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_aot_init
0x108153ba0 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_invoke_load_hook_internal
0x108154cb8 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_request_load_from
0x1081547c4 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_request_open
0x108156d48 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_open
0x107967160 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : xamarin_log
0x1081574f8 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_loaded_internal
0x108156974 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_request_byname
0x1080fcc54 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_aot_get_method_flags
0x1080f4144 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_aot_init
0x108153ba0 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_invoke_load_hook_internal
0x108154cb8 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_request_load_from
0x1081547c4 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_request_open
0x108156d48 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/Frameworks/Mono.framework/Mono : mono_assembly_open
0x10795ed78 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : xamarin_get_block_descriptor
0x10434b5d0 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : _ZN7plcrash2MS5async24dwarf_cfa_state_iteratorIyxE4nextEPjPNS1_28plcrash_dwarf_cfa_reg_rule_tEPy
0x107966e50 - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : xamarin_log
0x10434b97c - /private/var/containers/Bundle/Application/BF008523-C9AE-4E16-B9FC-0C818F485D55/Myapp.MobileApp/MyApp.MobileApp.Ios : _ZN7plcrash2MS5async24dwarf_cfa_state_iteratorIyxE4nextEPjPNS1_28plcrash_dwarf_cfa_reg_rule_tEPy
0x1a48a66b0 - /usr/lib/system/libdyld.dylib : <redacted>
=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x1d2bc6414):0x1d2bc6404 ff 0f 5f d6 c0 03 5f d6
10 29 80 d2 01 10 00 d4 .......)......
0x1d2bc6414 03 01 00 54 7f 23 03 d5 fd 7b bf a9 fd 03 00 91 ...T.#...{......
0x1d2bc6424 ff 71 ff 97 bf 03 00 91 fd 7b c1 a8 ff 0f 5f d6 .q.......{.....
0x1d2bc6434 c0 03 5f d6 90 29 80 d2 01 10 00 d4 03 01 00 54 ....).........T
=================================================================
Managed Stacktrace:
=================================================================
=================================================================
Related
Let's say I'm reading a TCP or UDP stream in Node Js. This question basically applies to any language or platform, but how do I go about creating a header for my data layer?
I suppose I need
A magic set of characters to identify a header
A number that says the length of the packet
???
I would like to future proof it and follow any "typical" data packet header structures (maybe they usually include version? protocol?) but cannot for the life of me find any great information online.
Use the pcapng format. The spec should have everything you need if you want to look at header bytes at a deeper level. Pcap is the older format, but has limitations.
There's already a pcapng parser available, pcap-ng-parser available via npm.
If you want a general protocol analyzer, you should look at Wireshark
Generate a pcapng file
In order to work with a pcapng, we need a pcapng file. Fortunately, tshark (part of Wireshark), makes this easy. We can use tshark to generate 10 packets (-c 10) and save to the pcapng format (-F).
tshark -w myfile.pcapng -F pcapng -c 10
JS pcapng libraries
pcap-ng-parser
We can use the sample js file on the about page:
# temp.js
const PCAPNGParser = require('pcap-ng-parser')
const pcapNgParser = new PCAPNGParser()
const myFileStream = require('fs').createReadStream('./myfile.pcapng')
myFileStream.pipe(pcapNgParser)
.on('data', parsedPacket => {
console.log(parsedPacket)
})
.on('interface', interfaceInfo => {
console.log(interfaceInfo)
})
Getting info from pcapng file
Running sample JS
Running it on my system, we see link and interface information.
$ node temp.js
{
linkType: 1,
snapLen: 524288,
name: 'en0\u0003\u0005Wi-Fi\t\u0001\u0006',
code_12: 'Mac OS X 10.14.6, build 18G103 (Darwin 18.7.0)\u0000\u0000\u0000\u0000\u0000\u0000h\u0000\u0000\u0000'
}
{
interfaceId: 0,
timestampHigh: 367043,
timestampLow: 1954977647,
data: <Buffer a8 bd 27 c8 f2 fe 6c 96 cf d8 7f e7 08 00 45 00 00 28 87 c3 00 00 40 06 e4 ba ac 1f 63 c6 8c 52 72 1a fc 3c 01 bb 6c 24 4d 01 54 03 1b 06 50 10 08 00 ... 4 more bytes>
}
... <output truncated>
Vs tshark
Depending on your use case, tshark may make more sense anyway
tshark -r myfile.pcapng -c 1 -T json
[
{
"_index": "packets-2019-12-15",
"_type": "pcap_file",
"_score": null,
"_source": {
"layers": {
"frame": {
"frame.interface_id": "0",
"frame.interface_id_tree": {
"frame.interface_name": "en0",
"frame.interface_description": "Wi-Fi"
},
"frame.encap_type": "1",
"frame.time": "Dec 15, 2019 12:04:14.932076000 PST",
"frame.offset_shift": "0.000000000",
"frame.time_epoch": "1576440254.932076000",
"frame.time_delta": "0.000000000",
"frame.time_delta_displayed": "0.000000000",
"frame.time_relative": "0.000000000",
"frame.number": "1",
"frame.len": "175",
"frame.cap_len": "175",
"frame.marked": "0",
"frame.ignored": "0",
"frame.protocols": "eth:ethertype:ip:udp:db-lsp-disc:json",
"frame.coloring_rule.name": "UDP",
"frame.coloring_rule.string": "udp"
},
"eth": {
"eth.dst": "ff:ff:ff:ff:ff:ff",
"eth.dst_tree": {
...
I'm developing the standard Node+Express web app. Everything else is working fine, but I can't make the .env file to populate process.env
At first, I thought it was a scope problem since my app.js, where dotenv is called from, is within the src subfolder and .env is in the root. But using node tools and confirming it with a package called find-config, I have the correct absolute path. I've never gotten an ENOENT for a file not found.
I tried everything, from dotenv's debug thingy explained in the docs, to my own debugging, making sure everything is in place. This is my latest attempt:
const fs = require('fs');
const realpath = require('find-config')('.env');
console.log(dotenv.parse(fs.readFileSync(realpath)));
I've paused execution and asserted that indeed realpath is exactly the absolute .env path
And here's .env
NODE_ENV=development
NODE_HOST=localhost
NODE_PORT=8080
SESSION_SECRET=eX&frsz9M*3XqFKUrK6
The console.log outputs {}, which is consistent with every avenue I've tried: never an error, never a parsed object either. Just nothingness.
Doing this:
const results = JSON.stringify(dotenv.config({"path":"/100%/correct/path/.env"}));
It throws back {"parsed":{}}
I've become so suspicious that I downloaded, installed and run the mega Hackathon Starter repo of 29k stars, which uses the same method.
Initially, it doesn't work because the author used a relative path. With the absolute path it works.
A bit more info in case it helps:
/* =========== Dotenv troubleshooting ===========
*/
const realPath = path.join(__dirname, '../.env');
const buffer = fs.readFileSync(realPath);
const envConfig = dotenv.parse(buffer, {debug:true});
l(realPath);
l(buffer);
l(envConfig);
/* end of Dotenv troubleshooting ------------------ */
This logs the following:
> node server.js
SESSION_SECRET=blabla value when parsing line 1: NODE_ENV=development
19:06:11 info: /100%/correct/path/.env
19:06:11 info: <Buffer 4e 4f 44 45 5f 45 4e 56 3d 64 65 76 65 6c 6f 70 6d 65 6e 74 0d 4e 4f 44 45 5f 48 4f 53 54 3d 6c 6f 63 61 6c 68 6f 73 74 0d 4e 4f 44 45 5f 50 4f 52 54 ... 41 more bytes>
19:06:11 info: {}
And as you can tell, that buffer is indeed the file:
/100%/correct/path $ xxd .env
00000000: 4e4f 4445 5f45 4e56 3d64 6576 656c 6f70 NODE_ENV=develop
00000010: 6d65 6e74 0d4e 4f44 455f 484f 5354 3d6c ment.NODE_HOST=l
After too much time scrutinizing my code, I finally discovered the issue.
Depending on operating systems and down to files themselves (and text editors and IDEs), at the end of the line you can have a Line Feed ("LF") character (0x0A, \n), Carriage Return ("CR") character (0x0D, \r) or End of Line ("EOL") character (0x0D0A, \r\n).
Unfortunately, dotenv only understands \n as the end of a line. So it was a parsing issue due to the simplicity of the checking. As far as I know, however, \n is kind of the standard.
For some reason, the .env file was using \r as a line separator. So it was a quick fix:
In my case, using a JetBrains product you can configure in the settings to always use the same end of line.
Using Node.js to download files containing music, in .m4a format.
Issue: I cannot find a way to add tags and the Cover Art (thumbnail) to .m4a files.
I had done this before using another program: achieved by MediaHuman youtube -> mp3 downloader (even though it downloads as m4a, my desired format) https://ufile.io/yzyzt
(P.S.I'm open to use another language, as long as the language can be linked it to node, but it is definitely very much preferred if it could be done purely in node.js)
Any clues on this subject are very appreciated.
One way to do it is to use node-taglib2, a Node.js C++ addon based on taglib and available in the npm repository.
This module makes trivial editing mpeg metadata:
const fs = require('fs');
const taglib = require('taglib2');
let props = {
artist: 'Howlin\' Wolf',
title: 'Evil is goin\' on',
pictures: [
{
"mimetype": 'image/jpeg',
"picture": fs.readFileSync('./thumbnail.jpg')
}
]
}
taglib.writeTagsSync('./file.m4a', props);
Now we can check that metadata have been updated:
let tags = taglib.readTagsSync('./file.m4a')
console.log(tags.artist, '-', tags.title) // Howlin' Wolf - Evil is goin' on
console.log(tags.pictures) // [ { mimetype: 'image/jpeg', picture: <Buffer ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00 ff db 00 43 00 03 02 02 03 02 02 03 03 03 03 04 03 03 04 05 08 05 05 04 04 05 0a 07 07 06 ... > } ]
But of course there are others options to do the same thing and I'm sure you could also use ffmpeg, as mentioned by Brad in his comment. I would be interested in your feedback if you try it.
I have finally solved my issue by the use of ffmpeg using node!
https://www.ffmpeg.org/
https://www.npmjs.com/package/ffmpeg
The issue was that \node_modules\ffmpeg\lib\video.js decided to skip duplicate commands, therefore my requests consisting of multiple of same commands were never read properly by ffmpeg. However, with a quick mod to the video.js file, I was able to make it work! I have successfully written both, the tags, and a thumbnail onto my .m4a
I have to debug a crash. But everytime my system crash it failed to dump the crashdump into the swap memory. The erorr i am seeing is:-
**Uptime: 7m32s
Dumping 3735 out of 131037 MB:..1%(ada0:ahcich0:0:0:0): WRITE_DMA48. ACB: 35 00 16 c9 c3 40 39 00 00 00 08 00
(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
(ada0:ahcich0:0:0:0): Error 22, Unretryable error
Aborting dump due to I/O error.
** DUMP FAILED (ERROR 22) **
**
In my rc.conf i have set the dumpdev to AUTO and my swap memory is 4GB.
Here is the ouput of fstab:-
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0p2 / ufs rw 1 1
/dev/ada0p3 none swap sw 0 0
Thanks
Your swap partition is smaller than your memory.
How do you expect 12 Gig to fit into 4Gig?
I have a user mode dump from Win 8.1/64, the dump was taken by attaching Windbg when the Wer dialogue. The .ecxr shows then ntdll!DbgBreakPoint for the Windbg injected thread. (As normal)
I have identified the thread by examine all stack, and finding the one which has :
# Call Site
00 ntdll!NtWaitForMultipleObjects
01 KERNELBASE!WaitForMultipleObjectsEx
02 kernel32!WerpReportFaultInternal
03 kernel32!WerpReportFault
04 KERNELBASE!UnhandledExceptionFilter
05 ntdll!RtlUserThreadStart$filt$0
06 ntdll!_C_specific_handler
07 ntdll!RtlpExecuteHandlerForException
08 ntdll!RtlDispatchException
09 ntdll!KiUserExceptionDispatch
10 <My faulty code which generated the exception>
The kvn aslo dispays a TrapFrame # 00000000`0379ed28)
09 00000000`0379e900 00000000`00250bc8 : 00000000`00000000 00000000`0026ca09 00000000`0379f160 00000000`0379f168 : ntdll!KiUserExceptionDispatch+0x2e (TrapFrame # 00000000`0379ed28)
Is there a way to use the trap frame to get the context record to feed into .cxr ?
Or is it other possibilities to find the exception context?
I see a KERNELBASE!UnhandledExceptionFilter on the stack. That seems like a good thing to focus on.
If this were x86, you could easily get an EXCEPTION_POINTERS struct out of the first parameter to KERNELBASE!UnhandledExceptionFilter. From there, you would have access to the EXCEPTION_RECORD and CONTEXT. The procedure is described in this KB article.
The same method works for x64 processes with one caveat. Due to the nature of the x64 calling convention, it is harder to retrieve the actual argument to KERNELBASE!UnhandledExceptionFilter since it is stored in a register rather than on the stack.
I recently found a debugger extension called CMKD that automates the task of hunting for the first 4 args in the x64 calling convention rather than blindly displaying stack values like kb and kv. This can be done by hand but it is a rather lengthy and error-prone process -- better to let an extension take a crack at it first.
With it, you can do something like this:
0:000> !cmkd.stack -p
Call Stack : 15 frames
## Stack-Pointer Return-Address Call-Site
[...]
03 000000aea3dae7e0 00007fff1e906b14 KERNELBASE!UnhandledExceptionFilter+196
Parameter[0] = 000000aea3dae930
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
[...]
And, now we have an EXCEPTION_POINTERS* in Parameter[0].
0:000> dt 000000ae`a3dae930 EXCEPTION_POINTERS
ConsoleApplication2!EXCEPTION_POINTERS
+0x000 ExceptionRecord : 0x000000ae`a3daf850 _EXCEPTION_RECORD
+0x008 ContextRecord : 0x000000ae`a3daf240 _CONTEXT
We can see in my example that a C++ exception was thrown...
0:000> .exr 000000ae`a3daf850
ExceptionAddress: 00007fff1bfeab78 (KERNELBASE!RaiseException+0x0000000000000068)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 4
Parameter[0]: 0000000019930520
Parameter[1]: 000000aea3daf9b0
Parameter[2]: 00007ff6f50024a8
Parameter[3]: 00007ff6f5000000
pExceptionObject: 000000aea3daf9b0
_s_ThrowInfo : 00007ff6f50024a8
Hopefully this helps. Good luck. :)
Another method fox x64 case doesn't require extension but is relying on two unstable facts:
windbg ability to reconstruct registers for a specific frame
the fact that WerpReportFault stores EXCEPTION_POINTERS address in rdi before passing it to WerpReportFaultInternal (it is the case at least for kernel32.dll 6.1.7601.23915 (win7sp1_ldr.170913-0600)
Exception pointer can be extracted as an rdi value of the WerpReportFault's frame:
0:007> k
# Child-SP RetAddr Call Site
00 00000000`0868dcd8 000007fe`fcf61430 ntdll!NtWaitForMultipleObjects+0xa
01 00000000`0868dce0 00000000`76fb16e3 KERNELBASE!WaitForMultipleObjectsEx+0xe8
02 00000000`0868dde0 00000000`7702b8b5 kernel32!WaitForMultipleObjectsExImplementation+0xb3
03 00000000`0868de70 00000000`7702ba37 kernel32!WerpReportFaultInternal+0x215
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
05 00000000`0868df40 00000000`7702bcac kernel32!BasepReportFault+0x1f
06 00000000`0868df70 00000000`77230108 kernel32!UnhandledExceptionFilter+0x1fc
07 00000000`0868e050 00000000`771c7958 ntdll! ?? ::FNODOBFM::`string'+0x2025
08 00000000`0868e080 00000000`771d812d ntdll!_C_specific_handler+0x8c
09 00000000`0868e0f0 00000000`771c855f ntdll!RtlpExecuteHandlerForException+0xd
0a 00000000`0868e120 00000000`771fbcb8 ntdll!RtlDispatchException+0x45a
0b 00000000`0868e800 000007fe`fe03df54 ntdll!KiUserExceptionDispatch+0x2e
0c 00000000`0868ef00 000007fe`fe03e1b6 gdi32!pmfAllocMF+0x2b0
0d 00000000`0868ef70 000007fe`fb10a646 gdi32!GetEnhMetaFileW+0x32
0e 00000000`0868efb0 000007fe`fb0c4959 GdiPlus!GpMetafile::GpMetafile+0x1c6
0f 00000000`0868f150 00000001`40001c35 GdiPlus!GdipCreateBitmapFromFile+0xc5
0:007> .frame /r 04
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
rax=00000000c0000001 rbx=0000000000000000 rcx=0000000002660000
rdx=0000000000000001 rsi=0000000000000001 rdi=000000000868e0b0
rip=000000007702ba37 rsp=000000000868df10 rbp=000000000868ff90
r8=000000000868d3f8 r9=000000000868d560 r10=0000000000000000
r11=0000000000000246 r12=000000000868e0b0 r13=0000000000000000
r14=0000000000000002 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000244
kernel32!WerpReportFault+0x77:
00000000`7702ba37 8b0d27ff0600 mov ecx,dword ptr [kernel32!RestrictedUserHandle+0xc (00000000`7709b964)] ds:00000000`7709b964=00000000
0:007> .exptr 000000000868e0b0
----- Exception record at 00000000`0868ecf0:
ExceptionAddress: 000007fefe03df54 (gdi32!pmfAllocMF+0x00000000000002b0)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 0000000000000000
Parameter[1]: 0000000002610028
Parameter[2]: 00000000c00000be
Inpage operation failed at 0000000002610028, due to I/O error 00000000c00000be
----- Context record at 00000000`0868e800:
rax=0000000002610000 rbx=000000000e5fe7c0 rcx=0000000000006894
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=000007fefe03df54 rsp=000000000868ef00 rbp=0000000000000104
r8=000000000868ee38 r9=0000000000000104 r10=0000000000000000
r11=0000000000000286 r12=0000000000000001 r13=000000006d9cf760
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
gdi32!pmfAllocMF+0x2b0:
000007fe`fe03df54 81782820454d46 cmp dword ptr [rax+28h],464D4520h ds:00000000`02610028=????????
I did some research and found two ways of getting it without any plugins, relying on WinDBG magic, etc.
First, invoke k command in WinDBG. Find a portion of stack like this:
Child-SP RetAddr
00000000`0ab7d9d0 00007ff9`98baed2d exception handler
00000000`0ab7da10 00007ff9`98b16c86 ntdll!RtlpExecuteHandlerForException+0xd
00000000`0ab7da40 00007ff9`98badc5e ntdll!RtlDispatchException+0x3c6
00000000`0ab7e140 00007ff9`98b5b48a ntdll!KiUserExceptionDispatch+0x2e
00000000`0ab7e860 00007ff9`96925531 Function that crashed
Now you can find what you want in local variables:
Option 1: Use EXCEPTION_POINTERS structure saved on stack
.exptr 00000000`0ab7da10 - 0x20
Option 2: Use CONTEXT and EXCEPTION_RECORD separately
.cxr 00000000`0ab7e140
.exr 00000000`0ab7e140 + ##c++(sizeof(ntdll!_CONTEXT)) + 0x20