Problem with MFD Export

(Reposting this here in hopes that maybe someone else will see it and be able to help)

In A-10C

I'm trying to use the Lo*SharedTexture methods in Export.lua but I'm running into lots of issues.

Any time I try to use those methods, I get an application exception:

Faulting application name: dcs.exe, version: 1.1.0.6, time stamp: 0x4d70d825

Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp: 0x4ce7c8f9

Exception code: 0xc0000005

Fault offset: 0x0000000000018e3d

Faulting process id: 0x7d8

Faulting application start time: 0x01cbe1d2e0b27fd7

Faulting application path: C:\Program Files\Eagle Dynamics\DCS A-10C\bin\dcs.exe

Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Report Id: 3af5e3cb-4dc6-11e0-a7bf-005056c00008

Here is a copy of my Export.lua in its entirety

-- Data export script for Lock On version 1.2.
-- Copyright (C) 2006, Eagle Dynamics.
-- See http://www.lua.org for Lua script system info 
-- We recommend to use the LuaSocket addon (http://www.tecgraf.puc-rio.br/luasocket) 
-- to use standard network protocols in Lua scripts.
-- LuaSocket 2.0 files (*.dll and *.lua) are supplied in the Scripts/LuaSocket folder
-- and in the installation folder of the Lock On version 1.2. 

-- Please, set EnableExportScript = true in the Config/Export/Config.lua file
-- to activate this script!

-- Expand the functionality of following functions for your external application needs.
-- Look into ./Temp/Error.log for this script errors, please.

-- you can export render targets via shared memory interface 
-- using next functions 
-- LoSetSharedTexture(name) -- register texture with name "name" to export
-- LoRemoveSharedTexture(name) -- copy texture with name "name" to named shared memory area "name"
-- LoUpdateSharedTexture(name) -- unregister texture
-- texture exported like Windows BMP file 
-- --------------------------------
-- |BITMAPFILEHEADER |
-- |BITMAPINFOHEADER |
-- |bits |
-- --------------------------------
-- sample textures : "mfd0" - full SHKVAL screen
-- "mfd1" - ABRIS map screen
-- "mfd2" - not used
-- "mfd3" - not used
-- "mirrors" - mirrors


local default_output_file = nil
local after_next_frame_called_once = false

function LuaExportStart()
LoSetSharedTexture("mfd0")
default_output_file = io.open("c:/Temp/Export.log", "w")
if default_output_file then
default_output_file:write("LuaExportStart was called.\r\n")
end
end

function LuaExportBeforeNextFrame()
end

function LuaExportAfterNextFrame()
LoUpdateSharedTexture("mfd0")
if default_output_file and not after_next_frame_called_once then
default_output_file:write("LuaExportAfterNextFrame was called.\r\n")
after_next_frame_called_once = true
end
end

function LuaExportStop()
LoRemoveSharedTexture("mfd0")
if default_output_file then
default_output_file:write("LuaExportStop was called.\r\n")
default_output_file:close()
default_output_file = nil
end
end

function LuaExportActivityNextEvent(t)
local tNext = t
return tNext
end

I left some of the default output file stuff in there for more diagnostics.

The Export.log file contains this:

LuaExportStart was called.
LuaExportAfterNextFrame was called.

Oddly enough, it's actually making it past the LoSetSharedTexture call into the file output call in LuaExportAfterNextFrame. At this point is when I get the ntdll.dll error.

I'm running Windows 7 x64, on a completely fresh install of A-10C updated to patch .6 using the x64 assemblies.

Just now I tried using the 32-bit assemblies and it actually creates the shared memory. I can see it using ProcessExplorer, and I can get a handle to it using .NET 4.0 MemoryMappedFile.OpenExisting. One problem - it's just a bunch of zeros.

Here is my code running in an x86 .NET assembly

 WriteStatusMessage("Trying to refresh MFD.");
try
{
using (var file = MemoryMappedFile.OpenExisting("mfd1"))
{
using (var stream = file.CreateViewStream())
{

byte[] data = new byte[stream.Length];
stream.Read(data, 0, data.Length);
File.WriteAllText(@"C:\Temp\Info.txt", string.Format("Data Length: {0}", data.Length));
File.WriteAllBytes(@"C:\Temp\bitmap.bmp", data);
}
}
}
catch (Exception ex)
{
WriteStatusMessage("Exception occurred refreshing MFD: {0}", ex.ToString());
}

bitmap.bmp is an empty file

Info.txt contains:

Data Length: 208896

When using the default configuration (256 textures).

If I bump the cockpit textures up to 1024 every frame the file is still just empty space, and info.txt now contains:

Data Length: 3158016

This also caused both visual studio and DCS to crash... I'm going to guess there's some memory stomping going on there. Or maybe some things not playing nice given the fact that it's throwing around 3MB of data. However, we can at least see that the data size is changing, so that's good.

Does anyone have any advice on if it's even remotely possible to get the MFD Exports to work in A-10? The use case I'm going for doesn't allow multiple monitors connected to the same computer as a viable alternative. I want this data via the network.

yeah, man

--texture exported just "like" Windows BMP file

--texture exported NOT "SAME AS" Windows BMP file

In fact, the LoSetSharedTexture exported BMP format is like this:

\x42\x4d\xOFF\xSET

BITMAPINFOHEADER/BITMAPINFO

\x00\x00\x00\x00

\x00\x00\x00\x00\x00\x00

raw RGB data......

CreateDIBitmap with this BITMAPINFOHEADER , BITMAPINFO and raw RGB data,

the BMP will like this: