Re: Need test for program loader accuracy; IPSM

From: Michael J. Salamone [eMVP] (mikesa#at#entrek#dot#com)
Date: 09/17/04


Date: Fri, 17 Sep 2004 07:13:38 -0700

What action would you take if you could detect the problem occurred?

Given the nature of the problem, you couldn't do it anyway because
presumably the part or the program that does the verification would be
"obfuscated" :) - unless you had an external program do it (using
ReadProcessMemory). But, that's pretty drastic testing, and not clear what
you would do if/when you detect the problem.

Best is to avoid it ever happening.

Here are some possibilities:
1) have a tiny process that launches your application. it copies it from
IPSM to main storage, and then launches the copy in RAM. Two drawbacks:
requires extra storage and takes longer to start your application (at least
the first time - the 2nd time, the app would be presumably in main storage,
so no need to copy again)
2) have a tiny debugger process that launches your app directly from IPSM.
When it gets notified of an exception, it handles it by nuking the process
and restarting it. Drawbacks are that you can lose or corrupt data (the app
did something "halfway" and then crashed causing the data to be
inconsistent/corrupt/not saved/whatever) and can be a bad user experience
(now you see my app where it is, now you don't, and now you see it starting
all over).
3) No guarantees that this will work, but do some testing on it to
determine: break your app into 1 or more DLLs. Then LoadLibrary/FreeLibrary
those DLLs as your application needs them. Since size is what matters here,
you will have vastly trimmed down the size of the main exe, plus only
certain parts will be loaded when needed.

I would go with solution 1) because it's easiest and will work. I would
avoid "solution" 2.

-- 
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com
"Vic Yuschuk" <vic@nospam.com> wrote in message 
news:uzucVsLnEHA.2216@TK2MSFTNGP10.phx.gbl...
> Does anyone have any ideas on how I could test whether the bits from my
> executables are being correctly loaded into RAM at runtime?
>
> Sorry about the cross-post flood, but it's hard to tell where I might find
> the best help with this issue - those who have seen it, those who know 
> Win32
> memory functions, general environment and OS gurus or system testers - and
> I've run out of time!
>
> I observe a variety of memory access symptoms in my app like data aborts,
> illegal instruction messages, and consistently garbled literal strings. 
> My
> situation is similar to what I've seen attributed to the Intel Persistent
> Storage Manager in newsgroups.  People say that IPSM can incorrectly load
> pages from executables in StrataFlash into RAM at runtime.  Like them, my
> problem does not appear when I run my application (not via XIP) from 
> copies
> of the executables stored in RAM instead of StrataFlash.  However, the
> application symptoms can change or disappear with even minor perturbations
> of the device, this is not very conclusive.
>
> Unfortunately, eVC++++ is behaving very badly for me.  The disassembler,
> variable and stack views often fail to show the right data so I can't use
> them to detect problems.  I have verified that the disassembler view is
> incorrect via trace statements that show that well-running parts of the
> application can have the correct code loaded while the disassembler 
> reports
> something else.  Unfortunately, looking individually at the first 20 
> machine
> instructions in WinMain(..) is not an approach I can easily use to more
> completely test memory loading of whole executables.
>
> 


Relevant Pages

  • Re: Need test for program loader accuracy; IPSM
    ... IPSM to main storage, and then launches the copy in RAM. ... have a tiny debugger process that launches your app directly from IPSM. ... > executables are being correctly loaded into RAM at runtime? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Need test for program loader accuracy; IPSM
    ... IPSM to main storage, and then launches the copy in RAM. ... have a tiny debugger process that launches your app directly from IPSM. ... > executables are being correctly loaded into RAM at runtime? ...
    (microsoft.public.windowsce.embedded)
  • Re: An idle rant
    ... computers sittin' around). ... running the production release app. ... > kindly ask you to think of your customers when you test your applications. ... 128Mb RAM and Win2K ...
    (borland.public.delphi.non-technical)
  • Re: Non-internet application wants to connect over internet
    ... > firewall that the app wants to connect to the internet. ... > itself to .Net executables, I made a note of the file size and the 'last ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Non-internet application wants to connect over internet
    ... > firewall that the app wants to connect to the internet. ... > itself to .Net executables, I made a note of the file size and the 'last ...
    (microsoft.public.dotnet.framework)