Member Avatar for ftl25

Hi

I am creating a DLL which will often make calls to another DLL. I have gone through the procedure of getting a handle to the other DLL and this works fine for some function calls. It seems like the functions which don't modify a parameter work fine. The access violation is occurring when a function takes a parameter which is modified. Some code:

// Function definitions
typedef int (__stdcall* LPFunction6) (LPSTR, LPSTR);
typedef int (__stdcall* LPFunction8) (short, short, long, long, short, LPSTR, LPSTR, short, short);

LPFunction6 DIAG_ReadMem32;
LPFunction8 DIAG_ConfigurationParameterSet;

// Get handle to dll
HINSTANCE hGetProcIDDLL = LoadLibrary("C:\\Windows\\System32\\UMASTER3XXXDPIL1.DLL");

// Get pointer to the function in the dll
DIAG_ReadMem32 = (LPFunction6)GetProcAddress(hGetProcIDDLL, "DIAG_ReadMem32");
DIAG_ConfigurationParameterSet = (LPFunction8)GetProcAddress(hGetProcIDDLL, "DIAG_ConfigurationParameterSet");

// User configuration parameters.
LPSTR memAddr = "FE000";
LPSTR returnData = "";

// Function calls
DIAG_ConfigurationParameterSet (0, 500, 1000, 10000, 0,	"c:\\windows\\system32\\pentcode.hex", "00001000", 0, 0);
iError = DIAG_ReadMem32(memAddr, returnData);    // This one is throwing access violation

I have tried also passing in the values to DIAG_ReadMem32, but to no avail.
Any help appreciated.

Edited by ftl25 because: n/a
  • 1 Contributor
  • 1 Reply
  • 645 Views
  • 8 Hours Discussion Span
  • Latest Post Latest Post by ftl25

Dani AI

Generated

As found, the access violation was caused by passing a non-writable pointer for an output parameter. Many Win32 APIs (and third‑party DLLs) expect a writable buffer for parameters they fill; a string literal (e.g. "...") is not guaranteed writable and converting it to char*/LPSTR is undefined behavior. Calls that only read the string can appear to work, but any function that writes into that pointer will crash.

There are a few other mistakes that commonly look like this, so check them too: make sure your function pointer prototype (calling convention and parameter types) exactly matches the DLL's exported signature (stdcall vs cdecl, ANSI vs Unicode/LPCWSTR, parameter count/types). A mismatch can corrupt the stack and produce crashes that only show up with certain parameters. Also ensure your process bitness matches the DLL (32‑bit vs 64‑bit).

A safe pattern is to allocate a real, sized buffer and pass its address. Example (C++11+):

std::string addr = "FE000";
std::vector<char> out(256);              // writable buffer
using ReadFn = int (__stdcall *)(const char*, char*);
ReadFn readFn = reinterpret_cast<ReadFn>(GetProcAddress(hModule, "DIAG_ReadMem32"));
int err = readFn(addr.c_str(), out.data());
// treat out.data() as a C string if the DLL writes a NUL-terminated string

Quick checklist: replace string literals with writable buffers or dynamically allocate the correct length; verify the exact prototype in the DLL docs or header; confirm ANSI/Unicode expectations; ensure 32/64‑bit compatibility; and run under a debugger to inspect the pointers and buffer contents right after the call. These steps explain why ’s switch to a real buffer fixed the crash and help avoid similar AVs.

Member Avatar for ftl25

I resolved this issue - I changed returnData from an LPSTR to a char array. This seems to have made the application quit its whinging.

char returnData[256];

// call function
iError = DIAG_ReadMem32(memAddr, returnData);
Edited by ftl25 because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.