Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 742
  • Last Modified:

CcriticalSection access violation in DLL

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
westcott
Asked:
westcott
  • 5
  • 3
  • 2
  • +1
1 Solution
 
Deepu AbrahamR & D Engineering ManagerCommented:
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
 
Deepu AbrahamR & D Engineering ManagerCommented:
While creating CCriticalSection object try to put the code in exception handling code.
try{
...
}catch(CMemoryxception& objMemEx) //or can use CException
{
...
}
0
 
westcottAuthor Commented:
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
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
Deepu AbrahamR & D Engineering ManagerCommented:
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
 
westcottAuthor Commented:
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
 
mxjijoCommented:

>> 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
 
westcottAuthor Commented:
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
 
mxjijoCommented:

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
 
westcottAuthor Commented:
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
 
AxterCommented:
>>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
 
westcottAuthor Commented:
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

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

  • 5
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now