Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Application Verifier for Windows Mobile 5.0 released

6 views
Skip to first unread message

Marty Larson (MS)

unread,
Feb 3, 2006, 4:18:17 PM2/3/06
to
The download for the WM5 app verifier is now live:

http://www.microsoft.com/downloads/details.aspx?FamilyId=D275348A-D937-4D88-AE25-28702C78748D&displaylang=en

--
Marty Larson [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


Frank S

unread,
Feb 6, 2006, 9:33:21 AM2/6/06
to
Marty Larson (MS) wrote:
> The download for the WM5 app verifier is now live:
>
> http://www.microsoft.com/downloads/details.aspx?FamilyId=D275348A-D937-4D88-AE25-28702C78748D&displaylang=en
>

Using the advice contained in this article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce50/html/appverifier_wince.asp

I am attempting to use the verifier (\Application Verifier for Mobile
5.0\Desktop\AppVerifCE.exe) with a Windows Mobile 5 Pocket PC device (hp
iPAQ) connected via USB. I have selected the Pocket PC 2003 device, and
am using the ActiveSync transport.

After I connect with AppVerifCE.exe, several files are downloaded to the
device, and then AppVerifCE.exe on the desktop hangs, consuming lots of
cpu. I never get to the "Add Application" dialog. (I know I have waited
for 5 minutes before giving up and killing AppVerifCE.exe.)

Any suggestions?

Thanks,

Frank

Marty Larson (MS)

unread,
Feb 6, 2006, 1:18:58 PM2/6/06
to
Hi, Frank,

I've never seen this problem before. Does it also repro with the CETK (I ask
since the 2 apps share quite a bit of the connection code).

The remote app is not a necessary component (there are other ways to
accomplish what it does, and it does not need to be running while testing
your app). You can also run appverif.exe on the device. With no arguments,
it'll pop up a UI on the device. You can also specify the applications and
the tests to apply on the command line:

appverif.exe -m <module to test, with extension> -s <shim dll to apply>

Ex.:
appverif.exe -m myApp.exe -s shim_heap.dll
appverif.exe -m myApp.exe -s shim_hleak.dll

--
Marty Larson [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Frank S" <Jazze...@online.nospam> wrote in message
news:u8pAJpyK...@TK2MSFTNGP11.phx.gbl...

Frank S

unread,
Feb 6, 2006, 3:17:36 PM2/6/06
to
Marty Larson (MS) wrote:
> Hi, Frank,
>
> I've never seen this problem before. Does it also repro with the CETK (I ask
> since the 2 apps share quite a bit of the connection code).
>
> The remote app is not a necessary component (there are other ways to
> accomplish what it does, and it does not need to be running while testing
> your app). You can also run appverif.exe on the device. With no arguments,
> it'll pop up a UI on the device. You can also specify the applications and
> the tests to apply on the command line:
>
> appverif.exe -m <module to test, with extension> -s <shim dll to apply>
>
> Ex.:
> appverif.exe -m myApp.exe -s shim_heap.dll
> appverif.exe -m myApp.exe -s shim_hleak.dll
>
Marty,

I don't have platform builder, so I can't answer the CETK question. (I
use Visual Studio 2005.)

I tried to run appverif.exe on the device, but it gets an error "can't
load the shim engine".

Some of the files that look related to app verifier look old on the
device (2004). Shouldn't these be copied to the device by running app
verify on the desktop?

I tried copying the /armvi/ files to the device (not sure if a specific
folder is required) but I still get the shim engine problem.

Given all these problems, can you give me detailed instructions on how
to use app verifier with a hp iPAQ Pocket PC device running Windows
Mobile 5 (SC32442-300MHz processor)?

Thanks,

Frank

Marty Larson (MS)

unread,
Feb 7, 2006, 3:14:52 PM2/7/06
to
Frank,

What's the date on the shimeng.dll on your device? Did you previously try to
use the CE (not Mobile) 5.0 app verifier on your device? If so, you'll need
to reset your device. Shimeng.dll is a kernel component, and one of the
properties of kernel components is that they cannot be unloaded. So, if
you've got an old shimeng.dll loaded, you wouldn't be able to just copy over
a new one. You'd need to reset your device (to unload the old shimeng.dll)
and then run app verifier again (which will load the new one included in
this package).

--
Marty Larson [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Frank S" <Jazze...@online.nospam> wrote in message

news:OSavhp1...@TK2MSFTNGP09.phx.gbl...

Frank S

unread,
Feb 7, 2006, 4:13:57 PM2/7/06
to
Marty Larson (MS) wrote:
> Frank,
>
> What's the date on the shimeng.dll on your device? Did you previously try to
> use the CE (not Mobile) 5.0 app verifier on your device? If so, you'll need
> to reset your device. Shimeng.dll is a kernel component, and one of the
> properties of kernel components is that they cannot be unloaded. So, if
> you've got an old shimeng.dll loaded, you wouldn't be able to just copy over
> a new one. You'd need to reset your device (to unload the old shimeng.dll)
> and then run app verifier again (which will load the new one included in
> this package).
>
Marty,

I hard reset my device, connected and established an ActiveSync
partnership, and ran the app verify on the desktop. I got the error
"Unable to launch device EXE".

I copied the \Arm4i files to the root of the device (which was just
about empty, as you would expect after a hard reset). I tried to run
appverif.exe on the device, and got the error "Unable to load shim
engine (shimeng.dll)".

I copied the \Arm4i files to the \Windows folder on the device. I tried
appverif.exe again, but got the shim engine error.

The \Arm4i\shimeng.dll is dated 1/25/2006 3:02:08 PM and is 14,032 bytes.

I tried app verify on the desktop again, and got the same "Unable to
launch device EXE" error.

Any other ideas on how to resolve my problem?

Thanks,

Frank


Frank S

unread,
Feb 7, 2006, 4:57:21 PM2/7/06
to
Marty,

More information...

Using a Treo 700w, I can get the app verifier to run on the device and
display part of the main dialog. Since the screen is small, a portion of
the dialog is off screen, so it does not seem usable.

From the desktop, I get the same "Unable to launch device EXE" error I
see using the hp iPAQ device.

Any suggestions?

Thanks,

Frank

Marty Larson (MS)

unread,
Feb 8, 2006, 12:04:54 PM2/8/06
to
Frank,

The UI will fit on a pocket pc-sized screen. Some of it does fall off the
smaller, square screen of the Treo.

In my earlier post, I mentioned that you don't need to use the UI (either
the desktop's, or the device's) to set up the test environment. Appverif.exe
also accepts the module you want to test and the tests to apply on its
command line.

Try creating .lnk files to launch appverif.exe and set up the testing
environment:

42#appverif.exe -m myApp.exe -s shim_heap.dll
43#appverif.exe -m myApp.exe -s shim_hleak.dll

(Be sure to adjust the leading number to reflect the length of your command
line after replacing 'myApp.exe' with the name of your module).

--
Marty Larson [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Frank S" <Jazze...@online.nospam> wrote in message

news:eqK%235FDLG...@TK2MSFTNGP09.phx.gbl...

Frank S

unread,
Feb 8, 2006, 5:38:15 PM2/8/06
to
Marty Larson (MS) wrote:
> Frank,
>
> The UI will fit on a pocket pc-sized screen. Some of it does fall off the
> smaller, square screen of the Treo.
>
> In my earlier post, I mentioned that you don't need to use the UI (either
> the desktop's, or the device's) to set up the test environment. Appverif.exe
> also accepts the module you want to test and the tests to apply on its
> command line.
>
> Try creating .lnk files to launch appverif.exe and set up the testing
> environment:
>
> 42#appverif.exe -m myApp.exe -s shim_heap.dll
> 43#appverif.exe -m myApp.exe -s shim_hleak.dll
>
> (Be sure to adjust the leading number to reflect the length of your command
> line after replacing 'myApp.exe' with the name of your module).
>
Marty,

Thanks, I am starting to make some progress. I can bring up the UI on
the device and it shows my .lnk file information, but I have yet to get
useful information.

If I want to check for heap problems (or everything) in a DLL, what is
the proper command. In this case, the dll is:

\Program Files\Company\My.dll

and the dll is loaded by this program:

\Windows\My.exe

Thanks,

Frank

Marty Larson (MS)

unread,
Feb 10, 2006, 4:49:27 PM2/10/06
to
Frank,

Instead of just trying to test a single dll, I'd suggest testing the entire
app (the app and every dll it loads). In that case, the command line (or,
lines, depending on what you're looking for) would be:

appverif.exe -m my.exe -s shim_heap.dll
appverif.exe -m my.exe -s shim_hleak.dll
appverif.exe -m my.exe -s shim_usergdi.dll

If you'd rather just test the dll, app verifier will allow that:

appverif.exe -m my.dll -s shim_heap.dll
etc...

You'll notice that only the filename is needed - not the entire path. After
you've got the test environment set up with those commands, you can run your
app, exercise its functionality, and app verifier will generate log files
(found in the root of the device) when the process exits.

The reason I don't recommend shimming specific dll's is that it can cause
problems when a pointer is shared between a shimmed and a non-shimmed
component. For example, if a shimmed module allocates memory, passes the
pointer to a non-shimmed module, and the non-shimmed module frees it, the
heap verifier will still think it's active. A worse problem is caused when a
non-shimmed component uses HeapSize to determine how much of the buffer is
writeable. The heap verifier will pad all allocations with a known pattern,
to make sure an app doesn't write past the requested bounds. If a
non-shimmed component queries this block with HeapSize, the heap manager
will return the total (requested + pad) size, which will then cause
corruption when the entire block is written.

--
Marty Larson [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Frank S" <Jazze...@online.nospam> wrote in message

news:%23XBkbBQ...@TK2MSFTNGP12.phx.gbl...

0 new messages