OK, now I experience another issue with it, I'm sorry.
Hopefully you can help me here as well.
I now want to call the callback function if an timer expires. Therefore I create an timer in a function I call from the main application. I store the handles to the timer and the timer queue globally in static variables.
static HANDLE gDoneEvent;
static HANDLE hTimer = NULL;
static HANDLE hTimerQueue = NULL;
int arg = 123; //will be passed to callback of timer
VOID CALLBACK TimerRoutine(PVOID lpParam, BOOLEAN TimerOrWaitFired)
if (lpParam == NULL)
//do some error handling her
//SetEvent(gDoneEvent); //for periodic calls, don't set gDoneEvent
Now, in some function called from the main application, I allocate the timer and start it:
// Use an event object to track the TimerRoutine execution
gDoneEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (NULL == gDoneEvent)
// Create the timer queue.
hTimerQueue = CreateTimerQueue();
if (NULL == hTimerQueue)
CreateTimerQueueTimer(&hTimer, hTimerQueue, (WAITORTIMERCALLBACK)TimerRoutine, &arg, 3000, 10000, 0);
WaitForSingleObject(gDoneEvent, INFINITE); //if we don't wait it crashes although handles are stored globally?
//the handles should be closed and deleted only after timer had occured.
////// Delete all timers in the timer queue.
//// printf("DeleteTimerQueue failed (%d)\n", GetLastError());
As you can see, I don't close the handles and delete the timer queue on purpose.
Everything works fine as long as the process waits. The callback in the main application is called.
If I comment out the line with WaitForSingleObject I'll get an access exception, although I stored all the handles globally. Teh exception occurs with the timing the timer would have. So most likely it tries to call the callback of the timer function but something is missing.
What is it I'm overlooking?
I need the dll running, not waiting inside a fucntion for a timer...
I need the dll running, not waiting inside a fucntion for a timer..
I am not sure what you mean by that. When you create a timer, it is designed to call some function after a specified period of time, either once or repeatedly. The reason for having the call to WaitForSingleObject, is in case the main code needs the timer event to complete some action first. But it is not necessary if the remainder of the code does not rely on the actions of the timer event.
yes, I know that. I did put that in, because I got the exception and wanted to try the example code. This worked two times, so I thought it must be caused by leaving the function. Unfortunately thsi is not the case:
After some debugging runs it seems that (in rare cases) it works a few times, but most likely it crashes immediately. So the observation I made that it is working if I call WaitForSingleObject isn't correct, it can crash randomly with or without.
Unfortunately when it crashs the program pointer isn't on frame any more, so I don't see why it does that.
One observation I made is that the handle of gDoneEvent is allocated in an entirely different address room (0x000003b0) than the other two handles hTimer and hTimerQueue(0x008b8928 and 0x008bsomething) which seems strange to me, since I thought allocated event should be also pretty close to the handles, but obviously it is not.
You never asked a question, but based on what other people are doing lately, it seems you're just trying to post your homework assignment from Chegg Study, thinking someone is going to write the code for you.
I have a C DLL that processes data for a MFC C++ program. It happens to be my FTP folder where files are received from FTP. when I step thru the code under the VS debugger everything runs fine
I make a breakpoint in the MFC code and when after getting the ProcAddress I go into the function.
So how do I know what the problem is when I don't run under the VS debugger, well I have a SEH (handler that pops up with a messagebox and I attach the debugger and observe the rc from _sopen_s that fails)
I decided to put a MessageBox in when it fails (in the DLL) and upon entry to the DLL as well, in the hope that I can then attach the debugger and get a better idea but the messagebox fails to appear I do re-link the MFC program as well
I went as far a deleting the .lib TO ensure I was picking it up while linking the MFC program and I got a link error so I know its picking the .lib of the DLL
I am running both the (VS Debugger and the MFC program in administrator mode)
Well it could be any one of a million things, but without more information it is pointless trying to guess. Also deleting the .lib file does not guarantee that you are loading the correct .dll at execution time. You should start by rebuilding everything from clean to ensure that no component is out of sync. Secondly, and much more importantly, where does the EACCESS* error occur, and what is the code trying to do at that point?
*EACCESS is returned (most often) when trying to access some file/directory that is protected. And even when running in admin mode some things remain blocked.
It’s a mainframe z/os sysadata file which is a binary representation of Z/OS Assembler program listing I have all the big endian conversion routines for going from mainframe to pc it did work as I was able to display the listing in the richedit that called the DLL and processed this file thanks