+2  A: 

Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.

ctacke
Thanks for answer. No, it's pure C module. Looks like the problrm is in PE-loader.
zxcat
What tool are you using to generate the binaries? I've never seen this problem, and I've run stuff compiled back with the old 3.0 tools user 6.x.
ctacke
It's mot me. The DLL developer is not accessible anymore. Looks like it was MSVS 2003 arm compiler.
zxcat
A: 

This problem is rare, but some information can be found.

The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.

I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.

This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.

In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...

And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).

I don't like this workaround, so I try to find some binary patcher. And found it :)

It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.

zxcat