How do I diagnose this crash?

The Map file looks like:

0002:000442e4 00000118H .idata$2                DATA   
0002:000443fc 00000014H .idata$3                DATA   
0002:00044410 00000b7cH .idata$4                DATA   
0002:00044f8c 0000512eH .idata$6                DATA   
0002:0004a0ba 00000000H .edata                  DATA   

The Crash info looks like:

Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".

I'm trying to get a stack dump on the next crash, but it seems to me this is a case where we trounced the stack, then did a return, which made us end up executing data.

I'm not entirely certain though because I read some articles like this: Under the Hood Article seems to indicate this is an area of imported method names

The data that an import library provides for an imported API is kept in several sections whose names all begin with .idata (for instance, .idata$4, .idata$5, and .idata$6). The .idata$5 section contains a single DWORD that, when the executable loads, contains the address of the imported function. The .idata$6 section (if present) contains the name of the imported function. When loading the executable into memory, the Win32 loader uses this string to call GetProcAddress on the imported function effectively.

Without a stack backtrace I'm kind of stuck. Am I looking at this crash the wrong way?

Forget MAP files, better use PDB files. For this enable linker option /DEBUG - yes, even for Release builds. /DEBUG is linker option, _DEBUG is compiler option. Only _DEBUG controls the code, and any conditional compilation that source/headers have put against this.

Debug builds have optimizations disabled, _DEBUG macro enabled. Release builds have optimizations enabled, _DEBUG macro disabled. /DEBUG would just put debugging-information into the EXE/DLL, and wont affect anything else.

Coming back to problem, when crash occurs. Do NOT close the application when WER (Windows Error Reporting) says it crashed. Instead keep it there, goto Task Manager, goto Process tab, select that crashed/crashing process, and hit "Create Dump File". Dump file (full-dump) will be created in some local folder (the path will be shown by task-manager). You can now close the crashing application (the WER window).

Now copy this .DMP file into some safe location, preferably the folder having your original Release folder. Open it in Visual Studio or WinDbg. On VS, just hit F11/F10, and you will be shown call stack. If multiple threads are running (in your crashed application), launch "Threads" view, and see the only suspended thread, double click it and you'll find the crash location.

You must have correct PDBs along with all binaries, and absolutely same code to see Code, otherwise call stack wont be good.

To get more information about PDB and stuff, you can read this article.