My IM application setup is much like below:

  • Interface module (exe)
  • Wordpress plugin module ( A polymorphic DLL that delivers an abstract interface for various methods towards the UI module )
  • Several Protocol DLLs ( Shared library DLLs that implement the particular methods, like Jabber, ICQ etc )

Now, I had been requested to implement contact list caching feature which meant doing File I/O.

Since File I/O can't be completed in the protocol DLLs ( it can't access the programs private folder ) I implemented a category drawing from an abstract class interface within the interface module.

Then i uncovered the abstract interface towards the Wordpress plugin module and protocol DLLs.

Allow that to abstract interface be named MFileService.

In the protocol DLL this is the way I recieve a clear case of MFileService derived class:

  1. Protocol DLL calls an online function on wordpress plugin object to obtain a pointer to MFileService derived object

  2. Wordpress plugin object calls an online function around the interface module.

  3. The interface module produces a clear case of MFileService dervied class and returns it towards the caller ( The wordpress plugin object )

  4. The wordpress plugin object inturn returns it towards the protocol DLL.

The issue is my application is crashes with KERN-Professional 3 at step one when its creating a virtual function call to wordpress plugin object.

HINTS:

  • All of the virtual function calls designed to the wordpress plugin object in the protocol DLL works except the main one I lately added.

  • The virtual function I recently put into the wordpress plugin and interface modules return a pointer to MFileService.

  • I haven't released the virtual functions since each one is pure virtual.

KERN-Professional 3 normally means an Access Breach. This most likely implies that MFileService wasn't correctly initialized within the wordpress plugin DLL.

  1. Check to make sure MFileService was correctly produced.
  2. Make sure that the harness is asking the right access point within the DLL. This really is often the first function within the DLL (Look into the .def file)
  3. Make sure that the wordpress plugin DLL really includes a valid value for MFileService Prior to the protocol DLL is produced.

With no code, I am unable to provide you with more detail than this.

Since File I/O can't be completed in the protocol DLLs ( it can't access the programs private folder )

This is actually not too. DLL code runs along the way (exe) context and may basically do regardless of the primary exe can, including being able to access its private directory data cage.