Dll Loading from WINCE driver using LoadLibrary.

    General discussion

  • Hi, 

    I have a dll, which is built is MFC application code. I want to load this dll from my one of my WINCE 5.0 driver and send data from here to my MFC dll. The dll is residing in SD card in a system. When I directly try load this MFC built dll from WINCE driver code, I always get a error 126 or 193. However the dll is built for a platform of wince (SDK). I have also used the CEWiz app to copy the dlls to \\windows folder and load from there.  As per article (Windows CE: LoadLIbrary fails with error code 193 - Bruce Eitman) , I have used the app to verify all the dependency files and included them in the same path. 

    We are using a our device SDK (which is on ARM4), and i am loading the dll from same system .  We have used same SDK to build the dll.  More info: The dll is built in visual studio 2008 and built for our deice SDK. The dll also contains some of the MFC code sections in it.

    Please provide me your valuable suggestions on this.



    Friday, September 06, 2013 12:13 PM

All replies

  • So this is a bad idea. The MFC DLL will not have the context that MFC expects and you're VERY likely to crash as soon as you call it, even if you can get it loaded. A non-MFC DLL built to run in the driver's context would probably work and you could test that easily with a DLL containing only 1 function call.

    Let's back up and get a real problem description so we can recommend a good solution. What does the DLL do with the data? What sort of data is it (integer, float, how much data per "packet")? How often does the data appear (how frequently do packets of the size just mentioned get sent to the DLL)? Is communication 1-way or 2-way (does data also come back to the driver from the DLL or not)?

    Paul T.

    Friday, September 06, 2013 11:03 PM
  • Hi Paul, 

    To give more details about the interface I require, 

    We have a requirement to read the stroke path, which are enumerated from the GDI driver. And this driver (test)  which is for drawing objects in the application using DC created by this driver. The driver is included in the WINCE OS build which is loaded in Kernel mode. 

    Once we read these points here,  we need to send these points to one of dll (x.dll) which is a MFC shared dll built in vs2008 which is also part of out UI MFC application . these dll will further applies some algorithm on these points and will be used further. 

    Hence we need to load this x.dll from the wince driver (test) and send the X, Y points which we get from DrvStrokePath enumeration to the mfc built dll (x.dll)

    Provide your valuable inputs on this, 



    Tuesday, September 10, 2013 11:32 AM
  • Can you load the DLL from an application using LoadLibrary?

    Are the APIs ready when you LoadLibrary from the driver?  BTW, my guesss is that they are not since you are trying to load it from your Display Driver.  One way to test this is to start a thread to load the library, then have the tread sleep for a rediculously long time, like a minute, then call LoadLibrary.

    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG

    Eurotech Inc.

    Tuesday, September 10, 2013 4:20 PM
  • I think your architecture is wrong. While its admirable trying to share the same DLL between your application and your driver this will be a dead end. Create a second DLL designed only to perform those operations needed by the driver currently implemented in the shared MFC DLL. Compile this DLL for kernel mode and load/call it from your driver. This should work, although you have to be careful when you call LoadLibrary (not during a Power event, for example).

    If desired you can also compile the same DLL source code for user mode and have your MFC-referencing DLL load and call the same functions (at the source level) as the driver. You'd have MyUtilDll_user.dll and MyUtilDll_kernel.dll.

    If you are actually trying to use DLL calls as a form of interprocess communication between driver and application (you are actually sending the points to the "application" context where they will be stored or used), forget about that and choose a different method to communicate between driver and application (or make the driver not be a driver).

    Paul T.

    Wednesday, September 11, 2013 5:56 PM
  • Hi Paul,

    Thanks for the inputs. As per the inputs, I created a separate dll called Interface dll, which is not shared between any other dll and used only to send the stroke path points from WINCE driver to the application.

    In this case, I am able to successfully open the dll and receive the points at application side. However when I try to send these points also if I try to access some other fucntion/class of the other compent (part of other dll) in a application, the exception occurs,

     The error says: Unhandled exception is an unknown module.(Cx0000005:Access Violation)

    In output window:

     304759 PID:b3b38242 TID:936ca7a2 0x936ecb50: Prefetch Abort: Thread=936ecb50 Proc=916cd3e0 'gwes.exe'
     304759 PID:b3b38242 TID:936ca7a2 0x936ecb50: AKY=00000091 PC=00004b04(???+0x00004b04) RA=01221134(smartxy.dll+0x00001134) BVA=00004b04 FSR=000004f0
     304771 PID:b3b38242 TID:936ca7a2 0x936ecb50: ERROR: d:\macallan\private\winceos\coreos\gwe\gwe\gwe_s.cpp line 1199:
     304771 PID:b3b38242 TID:936ca7a2 0x936ecb50: An exception occurred in GWE at 00004b04.

    Note: i tried to open this dll which is successfula and able to send these received points to other components a dllm there in no exception here.

    Please suggest how to remove this dependancy and access other componet functions/classes from this new interface dll.






    Friday, October 11, 2013 12:58 PM
  • So an access violation indicates a) you dereferenced a pointer to a "bad" location (like a null pointer), b) you passed some parameter to some call that did the "bad" location reference for you.

    It sounds like the point transfer works fine. You call some other functions we know nothing about and you get a crash? Without knowing what those things do and how they were intended to be called we have no way to even suggest what you do next. The debugger will probably stop when the exception occurs if that helps. Looking at the stack might tell you which call caused your problem.

    Paul T.

    Tuesday, October 15, 2013 6:29 PM