Diagnose BEX event, exception code 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN)

I build a program via the IDE CVI/LabWindows from National Instruments. This program runs fine. I actually include a dll for modbus functionality (libmodbus) that I compiled via Microsoft Visual C++ Express 2008. All together runs fine for few days and then crashes. I figured out via the event viewer that the problem is the modbus.dll. I compiled a newer one V3.1.10 (However, the version is inserted incorrectly in modbus.dll V3.1.1.2) and run my app for almost a month without any crash but now it happens again, I don't know why. I think it only happens when a Modbus master fetches the data from the PC running my program (so some reply functions inside modbus.dll will react).

I always got 2 same (same address offsets) error entries (and few informational ones) that say:

Faulting application name: HyF5674.exe, version: 0.1.16.0, time stamp: 0x647058bb
Faulting module name: modbus.dll, version: 3.1.1.2, time stamp: 0x645e1045
Exception code: 0xc0000409
Fault offset: 0x00005c2a
Faulting process id: 0x1a70
Faulting application start time: 0x01d98f9fa71ab269
Faulting application path: C:\Program Files (x86)\BBS\HyF5674\HyF5674.exe
Faulting module path: C:\Program Files (x86)\BBS\HyF5674\modbus.dll
Report Id: a551cd66-3b3d-46d0-a779-870d8c07ad93
Faulting package full name: 
Faulting package-relative application ID:

following by this:

Faulting application name: HyF5674.exe, version: 0.1.16.0, time stamp: 0x647058bb
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x9b42782d
Faulting process id: 0x1a70
Faulting application start time: 0x01d98f9fa71ab269
Faulting application path: C:\Program Files (x86)\BBS\HyF5674\HyF5674.exe
Faulting module path: unknown
Report Id: d4833275-82d0-4b4f-8184-326f7fed350a
Faulting package full name: 
Faulting package-relative application ID:

and the information:

Fault bucket , type 0
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: HyF5674.exe
P2: 0.1.16.0
P3: 647058bb
P4: modbus.dll
P5: 3.1.1.2
P6: 645e1045
P7: 00005c2a
P8: c0000409
P9: 00000015
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER831A.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8609.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8667.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER8675.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER86C4.tmp.txt
\\?\C:\Users\benke\AppData\Local\Temp\WER8715.tmp.appcompat.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_HyF5674.exe_588ac012ed775396d11723c0afcf3145a6f825e7_bca12235_cab_431f876f\memory.hdmp

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_HyF5674.exe_588ac012ed775396d11723c0afcf3145a6f825e7_bca12235_cab_431f876f

Analysis symbol: 
Rechecking for solution: 0
Report Id: a551cd66-3b3d-46d0-a779-870d8c07ad93
Report Status: 4
Hashed bucket: 
Cab Guid: 0

I downloaded the DbgHelper and put the offset address 0x00005c2a into the "query dll relative address" (I got this from an post here). The function modbus_report_slave_id is highlighted but on the right there is a info "File and line number unavailable, Function modbus_report_slave_id, address 0x00685C2A". I don't know if I do it right, I never debug dlls before. Can anyone help me with this worse problem?

What I've done until now: Use DbgHelp to find out the function that produce the stack buffer overflow.

To look into this you need:

1. Dump file generated by the system
2. The .pdb files generated by the compiler
3. An understanding of the code that crashed
4. An understanding of what the exception information is telling you

Once you have the dmp file you can open it in visual studio and if it loads the required pdb's then you should be enough information to start looking at the issue.

The setup I like to do is which give the best information:

1. Setup the dump file location / dump type to a easier to find folder location and full dump type to give you the most information possible. e.g. DumpFolder = c:\crashdumps, DumpType = 2 (full dump)
2. Setup visual studio options / debugging / symbols have the Micrsoft Symbol Server selected - this may give useful information when things are calling into / output windows runtime functions. I also add another symbol path pointing to a directory (e.g. c:\symbols) where I copy by compiled pdb files to if required.

When you open up the dmp file in visual studio, you should be able to see the stack trace of the faulting exception (and any other thread stacks as well) with source code. You should be ale to see exception information as well. You may/may not be able to see local / stack variables / parameters (this is where a full dump is better as then you should see local and global variables).

You also need to know what STATUS_STACK_BUFFER_OVERRUN actually means. See this blog post to try to understand why this happens. Since this is not a processor stuctured exception then it was manually raised by something. So your faulting stack trace should give some sort of indication why this is happening.

Without the faulting stack trace it's hard to give more advice, other than trying to understand the why the code is calling the said functions down the call stack and this may point to the problem.