DLL "Registration" in .NetCF?

  • Thread starter Thread starter Tim Johnson
  • Start date Start date
T

Tim Johnson

I have a legacy C++ dll that I P/Invoke into from a C# app. If I package it
up into my installer cab and deploy it to /Windows, then immediately run the
installed app, I get a MissingMethodException as though the dll is not there
(but I see it). If I copy it to my app's directory I get the same behavior
until I soft-reset.

If I soft-reset, it seems to then work MOST of the time. But then about 15%
of the time, I get it again. Soft reset helps again. So it's not just a
matter of how the cab installer puts the dll file into /Windows, it kind of
disappears during normal use somehow.

Is there any sort of "dll registration" step that is required on PPC to make
WindowsCE not forget about this dll? I thought just putting it in /Windows
was all you need. My dllimport just gives the name of the dll, should I
specify a fully qualified path, and would that make things better? In
testing this all works great but with extended use of an hour or so,
sometimes less, suddenly I can't p/invoke any more and get the MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Nope, just the one. It starts out being accessible via pInvoke, then
sometime during extended execution, or with another launch of the app later,
I start getting MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
DllImport("BTAccess.dll"). Not likely it's duplicated anywhere. The
frustrating thing is it works for a while, then suddenly the OS can't find
it unless I reset.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Actually it sounds like it might. Is it possible to rename it and try like
that?
 
It almost sounds like the loader is having its search path changed by
something during execution. You might check
HKEY_LOCAL_MACHINE\Loader\SystemPath after install of the DLL and then when
it fails and just see if it changed (note that it's a multi-string item, so
you have to open it in Remote Registry Editor to see all of the entries).

Paul T.
 
When it fails and I look there I see this value for SystemPath:

"\Release\Storage\Windows".

Does that seem strange to anyone? Clearly my dll is not there!

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
Remember that it's a multi-string value, not just a single string. Did you
double-click the value name in Remote Registry Editor and verify that only
the one path is there (you can't just look at it in the main display; that
only shows the first entry)? The fact that \Release is there suggests that
you're running the RelFsd driver (allowing a Platform Builder system to
treat files in the flat release directory as though they were on the
device), or something. You might double-check that...

Paul T.
 
I saw it on 2 lines, as in:

\Release\
\Storage\Windows\


Maybe that's really parsed as 3 places to look for dlls - \Release, then
\Storage, and finally \Windows? I do also see this in the registry re: SFD:


[HKEY_LOCAL_MACHINE\System\Events]
"SYSTEM/ShellAPIReady"=""
"SYSTEM/PowerManagerReady"="Power Manager APIs"
"SYSTEM/GweApiSetReady"="Event triggered after GWES registers its API sets"
"ReleaseFSD"="ReleaseFSD"

Another clue - at the times I get the missingmethod exception, I run a very
small test app that tries to use the same dll. And it works. So now I'm
wondering if my much larger app, which uses maybe 10-12 other dlls I know
about directly, plus who knows how many others in due course, is suffering
not from an inability to find the dll, but an inability to load it.

Is there some dll-count limit I may be exceeding? I seem to recall
something about a 32-slot process limit. I notice this happens more often
but not exclusively when I utilize the CDMA phone to make the web
connections my code requires. Maybe all tolled I've simply got too much
going on? Could the MMEx be cause by something like that?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
 
No, if it's on two lines, there are two strings in the value. Each is
searched as a complete path. The presence of the \Release folder, though,
suggests that you are running the driver I mentioned last time. I'd try
removing that, in the interest of having as few wildcards running around as
possible.

There are a variety of limitations: 32 process slots (but DLLs don't take up
slots; processes do). Each process gets 32MB of memory space and, if you
are loading a lot of DLLs, it's just possible that you're running out
somehow. You really need to build a DEBUG OS, it sounds like, and read the
debug output messages when the error occurs. I think there's a reasonable
chance that doing so would tell you what's going on.

As far as missing method exceptions, it might mean that there are two copies
of a target DLL floating around and they don't have the same set of exports.
Sometimes you get DLL #1 and all is well, while other times you get DLL #2
and you get the exception.

Paul T.

Tim Johnson said:
I saw it on 2 lines, as in:

\Release\
\Storage\Windows\


Maybe that's really parsed as 3 places to look for dlls - \Release, then
\Storage, and finally \Windows? I do also see this in the registry re:
SFD:


[HKEY_LOCAL_MACHINE\System\Events]
"SYSTEM/ShellAPIReady"=""
"SYSTEM/PowerManagerReady"="Power Manager APIs"
"SYSTEM/GweApiSetReady"="Event triggered after GWES registers its API
sets"
"ReleaseFSD"="ReleaseFSD"

Another clue - at the times I get the missingmethod exception, I run a
very small test app that tries to use the same dll. And it works. So now
I'm wondering if my much larger app, which uses maybe 10-12 other dlls I
know about directly, plus who knows how many others in due course, is
suffering not from an inability to find the dll, but an inability to load
it.

Is there some dll-count limit I may be exceeding? I seem to recall
something about a 32-slot process limit. I notice this happens more often
but not exclusively when I utilize the CDMA phone to make the web
connections my code requires. Maybe all tolled I've simply got too much
going on? Could the MMEx be cause by something like that?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Paul G. Tobey said:
Remember that it's a multi-string value, not just a single string. Did
you double-click the value name in Remote Registry Editor and verify that
only the one path is there (you can't just look at it in the main
display; that only shows the first entry)? The fact that \Release is
there suggests that you're running the RelFsd driver (allowing a Platform
Builder system to treat files in the flat release directory as though
they were on the device), or something. You might double-check that...

Paul T.

Tim Johnson said:
When it fails and I look there I see this value for SystemPath:

"\Release\Storage\Windows".

Does that seem strange to anyone? Clearly my dll is not there!

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message It almost sounds like the loader is having its search path changed by
something during execution. You might check
HKEY_LOCAL_MACHINE\Loader\SystemPath after install of the DLL and then
when it fails and just see if it changed (note that it's a multi-string
item, so you have to open it in Remote Registry Editor to see all of
the entries).

Paul T.

Actually it sounds like it might. Is it possible to rename it and try
like that?

--
Alex Feinman
---
Visit http://www.opennetcf.org
DllImport("BTAccess.dll"). Not likely it's duplicated anywhere. The
frustrating thing is it works for a while, then suddenly the OS can't
find it unless I reset.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Out of interest what is the name of the dll, does it have the same
name as another dll or exe on the device?

Peter

--
Peter Foot
Windows Embedded MVP
http://www.inthehand.com | http://www.peterfoot.net |
http://www.opennetcf.org

Nope, just the one. It starts out being accessible via pInvoke,
then sometime during extended execution, or with another launch of
the app later, I start getting MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Do you perhaps have an identically named DLL elsewhere?

--
Alex Feinman
---
Visit http://www.opennetcf.org
I have a legacy C++ dll that I P/Invoke into from a C# app. If I
package it up into my installer cab and deploy it to /Windows,
then immediately run the installed app, I get a
MissingMethodException as though the dll is not there (but I see
it). If I copy it to my app's directory I get the same behavior
until I soft-reset.

If I soft-reset, it seems to then work MOST of the time. But
then about 15% of the time, I get it again. Soft reset helps
again. So it's not just a matter of how the cab installer puts
the dll file into /Windows, it kind of disappears during normal
use somehow.

Is there any sort of "dll registration" step that is required on
PPC to make WindowsCE not forget about this dll? I thought just
putting it in /Windows was all you need. My dllimport just gives
the name of the dll, should I specify a fully qualified path, and
would that make things better? In testing this all works great
but with extended use of an hour or so, sometimes less, suddenly
I can't p/invoke any more and get the MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
Click to expand...
Click to expand...
Click to expand...
 
Ok - so my one process only takes up 1 of the 32 system slots, but each dll
I load takes up 32M of memory even if it doesn't really require that much.
So I could also keep an eye of available memory during these situations,
short of building the debug os. The 2-copies is very unlikely (famous last
words) since I can do a hard-reset and full install of my cab file and still
get the problem so I'm pretty sure there's only a single copy. Thanks very
much for the pointers, I'll keep at it.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Paul G. Tobey said:
No, if it's on two lines, there are two strings in the value. Each is
searched as a complete path. The presence of the \Release folder, though,
suggests that you are running the driver I mentioned last time. I'd try
removing that, in the interest of having as few wildcards running around
as possible.

There are a variety of limitations: 32 process slots (but DLLs don't take
up slots; processes do). Each process gets 32MB of memory space and, if
you are loading a lot of DLLs, it's just possible that you're running out
somehow. You really need to build a DEBUG OS, it sounds like, and read
the debug output messages when the error occurs. I think there's a
reasonable chance that doing so would tell you what's going on.

As far as missing method exceptions, it might mean that there are two
copies of a target DLL floating around and they don't have the same set of
exports. Sometimes you get DLL #1 and all is well, while other times you
get DLL #2 and you get the exception.

Paul T.

Tim Johnson said:
I saw it on 2 lines, as in:

\Release\
\Storage\Windows\


Maybe that's really parsed as 3 places to look for dlls - \Release, then
\Storage, and finally \Windows? I do also see this in the registry re:
SFD:


[HKEY_LOCAL_MACHINE\System\Events]
"SYSTEM/ShellAPIReady"=""
"SYSTEM/PowerManagerReady"="Power Manager APIs"
"SYSTEM/GweApiSetReady"="Event triggered after GWES registers its API
sets"
"ReleaseFSD"="ReleaseFSD"

Another clue - at the times I get the missingmethod exception, I run a
very small test app that tries to use the same dll. And it works. So
now I'm wondering if my much larger app, which uses maybe 10-12 other
dlls I know about directly, plus who knows how many others in due course,
is suffering not from an inability to find the dll, but an inability to
load it.

Is there some dll-count limit I may be exceeding? I seem to recall
something about a 32-slot process limit. I notice this happens more
often but not exclusively when I utilize the CDMA phone to make the web
connections my code requires. Maybe all tolled I've simply got too much
going on? Could the MMEx be cause by something like that?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Paul G. Tobey said:
Remember that it's a multi-string value, not just a single string. Did
you double-click the value name in Remote Registry Editor and verify
that only the one path is there (you can't just look at it in the main
display; that only shows the first entry)? The fact that \Release is
there suggests that you're running the RelFsd driver (allowing a
Platform Builder system to treat files in the flat release directory as
though they were on the device), or something. You might double-check
that...

Paul T.

When it fails and I look there I see this value for SystemPath:

"\Release\Storage\Windows".

Does that seem strange to anyone? Clearly my dll is not there!

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com> wrote in message It almost sounds like the loader is having its search path changed by
something during execution. You might check
HKEY_LOCAL_MACHINE\Loader\SystemPath after install of the DLL and then
when it fails and just see if it changed (note that it's a
multi-string item, so you have to open it in Remote Registry Editor to
see all of the entries).

Paul T.

Actually it sounds like it might. Is it possible to rename it and try
like that?

--
Alex Feinman
---
Visit http://www.opennetcf.org
DllImport("BTAccess.dll"). Not likely it's duplicated anywhere.
The frustrating thing is it works for a while, then suddenly the OS
can't find it unless I reset.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Out of interest what is the name of the dll, does it have the same
name as another dll or exe on the device?

Peter

--
Peter Foot
Windows Embedded MVP
http://www.inthehand.com | http://www.peterfoot.net |
http://www.opennetcf.org

Nope, just the one. It starts out being accessible via pInvoke,
then sometime during extended execution, or with another launch of
the app later, I start getting MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


message Do you perhaps have an identically named DLL elsewhere?

--
Alex Feinman
---
Visit http://www.opennetcf.org
I have a legacy C++ dll that I P/Invoke into from a C# app. If I
package it up into my installer cab and deploy it to /Windows,
then immediately run the installed app, I get a
MissingMethodException as though the dll is not there (but I see
it). If I copy it to my app's directory I get the same behavior
until I soft-reset.

If I soft-reset, it seems to then work MOST of the time. But
then about 15% of the time, I get it again. Soft reset helps
again. So it's not just a matter of how the cab installer puts
the dll file into /Windows, it kind of disappears during normal
use somehow.

Is there any sort of "dll registration" step that is required on
PPC to make WindowsCE not forget about this dll? I thought just
putting it in /Windows was all you need. My dllimport just
gives the name of the dll, should I specify a fully qualified
path, and would that make things better? In testing this all
works great but with extended use of an hour or so, sometimes
less, suddenly I can't p/invoke any more and get the MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
Click to expand...
Click to expand...
Click to expand...
 
No, each DLL doesn't take 32MB of memory. Each DLL takes whatever amount of
memory is needed to load the code. However, if you are loading a large
number of DLLs, you might reach the point where the stack size + heap size +
code size for EXE + code sizes for all DLLs is big enough to run you out of
memory. I've never had that happen, but it's possible.

I think that building a DEBUG version of the OS is going to easily be the
quickest way out of your problem.

Paul T.

Tim Johnson said:
Ok - so my one process only takes up 1 of the 32 system slots, but each
dll I load takes up 32M of memory even if it doesn't really require that
much. So I could also keep an eye of available memory during these
situations, short of building the debug os. The 2-copies is very unlikely
(famous last words) since I can do a hard-reset and full install of my cab
file and still get the problem so I'm pretty sure there's only a single
copy. Thanks very much for the pointers, I'll keep at it.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Paul G. Tobey said:
No, if it's on two lines, there are two strings in the value. Each is
searched as a complete path. The presence of the \Release folder,
though, suggests that you are running the driver I mentioned last time.
I'd try removing that, in the interest of having as few wildcards running
around as possible.

There are a variety of limitations: 32 process slots (but DLLs don't take
up slots; processes do). Each process gets 32MB of memory space and, if
you are loading a lot of DLLs, it's just possible that you're running out
somehow. You really need to build a DEBUG OS, it sounds like, and read
the debug output messages when the error occurs. I think there's a
reasonable chance that doing so would tell you what's going on.

As far as missing method exceptions, it might mean that there are two
copies of a target DLL floating around and they don't have the same set
of exports. Sometimes you get DLL #1 and all is well, while other times
you get DLL #2 and you get the exception.

Paul T.

Tim Johnson said:
I saw it on 2 lines, as in:

\Release\
\Storage\Windows\


Maybe that's really parsed as 3 places to look for dlls - \Release, then
\Storage, and finally \Windows? I do also see this in the registry re:
SFD:


[HKEY_LOCAL_MACHINE\System\Events]
"SYSTEM/ShellAPIReady"=""
"SYSTEM/PowerManagerReady"="Power Manager APIs"
"SYSTEM/GweApiSetReady"="Event triggered after GWES registers its API
sets"
"ReleaseFSD"="ReleaseFSD"

Another clue - at the times I get the missingmethod exception, I run a
very small test app that tries to use the same dll. And it works. So
now I'm wondering if my much larger app, which uses maybe 10-12 other
dlls I know about directly, plus who knows how many others in due
course, is suffering not from an inability to find the dll, but an
inability to load it.

Is there some dll-count limit I may be exceeding? I seem to recall
something about a 32-slot process limit. I notice this happens more
often but not exclusively when I utilize the CDMA phone to make the web
connections my code requires. Maybe all tolled I've simply got too
much going on? Could the MMEx be cause by something like that?

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message Remember that it's a multi-string value, not just a single string. Did
you double-click the value name in Remote Registry Editor and verify
that only the one path is there (you can't just look at it in the main
display; that only shows the first entry)? The fact that \Release is
there suggests that you're running the RelFsd driver (allowing a
Platform Builder system to treat files in the flat release directory as
though they were on the device), or something. You might double-check
that...

Paul T.

When it fails and I look there I see this value for SystemPath:

"\Release\Storage\Windows".

Does that seem strange to anyone? Clearly my dll is not there!

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com> wrote in message It almost sounds like the loader is having its search path changed by
something during execution. You might check
HKEY_LOCAL_MACHINE\Loader\SystemPath after install of the DLL and
then when it fails and just see if it changed (note that it's a
multi-string item, so you have to open it in Remote Registry Editor
to see all of the entries).

Paul T.

Actually it sounds like it might. Is it possible to rename it and
try like that?

--
Alex Feinman
---
Visit http://www.opennetcf.org
DllImport("BTAccess.dll"). Not likely it's duplicated anywhere.
The frustrating thing is it works for a while, then suddenly the OS
can't find it unless I reset.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


Out of interest what is the name of the dll, does it have the same
name as another dll or exe on the device?

Peter

--
Peter Foot
Windows Embedded MVP
http://www.inthehand.com | http://www.peterfoot.net |
http://www.opennetcf.org

Nope, just the one. It starts out being accessible via pInvoke,
then sometime during extended execution, or with another launch
of the app later, I start getting MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625


message Do you perhaps have an identically named DLL elsewhere?

--
Alex Feinman
---
Visit http://www.opennetcf.org
I have a legacy C++ dll that I P/Invoke into from a C# app. If
I package it up into my installer cab and deploy it to /Windows,
then immediately run the installed app, I get a
MissingMethodException as though the dll is not there (but I see
it). If I copy it to my app's directory I get the same behavior
until I soft-reset.

If I soft-reset, it seems to then work MOST of the time. But
then about 15% of the time, I get it again. Soft reset helps
again. So it's not just a matter of how the cab installer puts
the dll file into /Windows, it kind of disappears during normal
use somehow.

Is there any sort of "dll registration" step that is required
on PPC to make WindowsCE not forget about this dll? I thought
just putting it in /Windows was all you need. My dllimport
just gives the name of the dll, should I specify a fully
qualified path, and would that make things better? In testing
this all works great but with extended use of an hour or so,
sometimes less, suddenly I can't p/invoke any more and get the
MMEx.

--

Tim Johnson
High Point Software, Inc.
www.high-point.com
(503) 312-8625
Click to expand...
Click to expand...
Click to expand...
 
Back
Top