Solved

CcriticalSection access violation in DLL

Posted on 2007-04-01
15
717 Views
Last Modified: 2013-12-14
I have a program that is logging data from a main program and several dlls in the same process. I am using a CCriticalSection to ensure that only one thread has access to the log at any time. When I call the log program from a DLL, it prepares the log message OK, but when it call sEnterCriticalSection to actually write the message to the log, there is an access violation. The logger works OK outside of the DLL. I am declaring the log program outside of the scope of any program, so presumably it is in global memory somewhere. Can anyone help, please?
0
Comment
Question by:westcott
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
  • 2
  • +1
15 Comments
 
LVL 11

Expert Comment

by:DeepuAbrahamK
ID: 18834671
Few things:
How/Where are you creating it?
Is your handle valid?
Before calling lock itslef does it fail?
Your CCriticalsection object is global?

Best Regards,
DeepuAbrahamK
0
 
LVL 11

Expert Comment

by:DeepuAbrahamK
ID: 18834727
While creating CCriticalSection object try to put the code in exception handling code.
try{
...
}catch(CMemoryxception& objMemEx) //or can use CException
{
...
}
0
 

Author Comment

by:westcott
ID: 18837411
I am declaring the CCriticalSection outside of the scope of the main program, which should make it global. The handle is valid, at least in the main program, because I am able to log data. I pass a pointer to my logger program into the dll when I create the DLL. When I call the logger program from within the DLL, the logger is able to format my data properly, but when the logger calls EnterCriticalSection before writing the data to a file, a memory exception occurs in the "EnetrCriticalSection" code.
0
Salesforce Has Never Been Easier

Improve and reinforce salesforce training & adoption using WalkMe's digital adoption platform. Start saving on costly employee training by creating fast intuitive Walk-Thrus for Salesforce. Claim your Free Account Now

 
LVL 11

Expert Comment

by:DeepuAbrahamK
ID: 18837622
Seems like before your EnterCriticalSection...somewhere it is getting deleted..Is there any DeleteCriticalSection code before that? If you are using the CCriticalSection then the object will be deleted once it goes out of scope.Since you have said that it is of global scope then in theory there should not be any problem. Are you mixing Win32 SDK and MFC?
0
 

Author Comment

by:westcott
ID: 18837923
I'm not calling DeleteCriticalSection. I'm using MFC and likely Win32 SDK as well.
There is one significant thing that I neglected to mention: I don't encounter any problem when I run my program in debug mode from VS. I just have a problem when I run it in release mode.
0
 
LVL 8

Expert Comment

by:mxjijo
ID: 18847622

>> I pass a pointer to my logger program into the dll when I create the DLL
   I am sorry I'm confused , can you elaborate on this please ?  
1) In what form is your "logger program" ? Is it just a function or an allocated object ? or is it a second application ?

2) What do you mean by "creating a DLL" ? Loading into your program ? or building ?

3) How do you pass
    1) the pointer of the logger to the DLL ??
    2) the crit sec handle to the DLL
    3) the crit sec ptr to the logger fn ?

~j

0
 

Author Comment

by:westcott
ID: 18848939
1) The logger program is an allocated object
code:
Logger log;
main
{
log << "This" << "is a message from the" << "main program ";
// above writes "This is a message from the main program" to the log file
hinstLib = LoadLibrary ('myDLL")
PmProc = (PMPROC) GETSYM(hinstLib, "Function1");
dllclass = (PmProc) (CallbackHelper,morphclass,&dllpath,&persist,log,&msWorkingDirectory);      // call Function1
}
in myDLL:
log << "This" << "is a message from the" << "dll ";
// above calls the logger, and assembles the message "This is a message from the dll" in a buffer
// The logger calls EnterCriticalSection(critsection) before writing the buffer to the file.
// If i compile the VC++ programs in debug mode, the operation succeeds
// If I compile the programs in release mode, there is an access violation when I call EnterCriticalSection

2) The logger object contains either a pointer to the critical section or the critical section itself (I've tried both)
0
 
LVL 8

Expert Comment

by:mxjijo
ID: 18851838

Hmm.. interesting..  I would try these..

1) Check your code generation settings (Multithreaded/Multithreaded DLL etc). Check settings for the debug build and use the similar one for release build.

2) If I were you, I'll make the Logger a singleton. Let every module access the instance via a getInstance() method. That way you'll make sure 1) there will be only one instance of the logger. 2) The object will be in the heap.
0
 

Author Comment

by:westcott
ID: 18856565
Thanks for the suggestions.
1) I checked all of the code generation settings and everything appears to be OK there.
2) I will look into making the logger a singleton, although I have checked all of my code to ensure that there is only one instance of the logger. Currently, the logger is being initialized in only one place - the main program.
3)Is there a difference in the way that memory is initialized in debug mode as opposed to release mode? For instance, is all unused memory set to zero for debug mode or something?
0
 
LVL 30

Expert Comment

by:Axter
ID: 18936538
>>I am declaring the CCriticalSection outside of the scope of the main program, which should make it global.

That does not make it global.
You can not use CCriticalSection for this requirement.
You need a named mutex, and the name needs to be prefixed with global.
For more information on how to create a global mutex, see CreateMutex API function, and look at naming requirements for global mutex.
0
 

Accepted Solution

by:
westcott earned 0 total points
ID: 19299262
I apologize for not giving the solution that I found. The problem did lie with a variable that was unitialized in release mode, but was set to zero by the debugger in debug mode. Once I initialized the variable. the problem went away.
0

Featured Post

Salesforce Has Never Been Easier

Improve and reinforce salesforce training & adoption using WalkMe's digital adoption platform. Start saving on costly employee training by creating fast intuitive Walk-Thrus for Salesforce. Claim your Free Account Now

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

For most people, the WrapPanel seems like a magic when they switch from WinForms to WPF. Most of us will think that the code that is used to write a control like that would be difficult. However, most of the work is done by the WPF engine, and the W…
Have you tried to learn about Unicode, UTF-8, and multibyte text encoding and all the articles are just too "academic" or too technical? This article aims to make the whole topic easy for just about anyone to understand.
The viewer will learn how to synchronize PHP projects with a remote server in NetBeans IDE 8.0 for Windows.
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question