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

Platform Builder debug session slow to load module symbols

7 views
Skip to first unread message

richa...@my-deja.com

unread,
Apr 23, 2007, 12:46:52 AM4/23/07
to
Hi all,

I'm using CE 4.2 Platform Builder with a Hitachi SH4 based target,
with a debug connection using USB RNDIS from a windows XP workstation.

CE has all avaliable updates applied and the WinXP workstation is
fully service packed.

Sometime in the last while (not quite sure when, I've really only
"noticed" now that i've needed to do quite a bit of debugging and its
become unbearable) my setup has become ridiculously slow at
establishing a debug connection.

Our debug image builds to about 16 meg. The actual download (from
Target->Download/Initialise) takes about 1 minute (this seems normal)
but the subsequent phase in which PB loads symbols for the various
modules in the image, the point at which messages similar to the
following are appearing in PB's debug window....

Loaded symbols for 'C:\WINCE420\PUBLIC\SV270\RELDIR
\TRIMBLE_SHOTGUN2_SH4DEBUG\IPHLPAPI.DLL'
4294780235 PID:2ffc1bde TID:aff3d646 0x8ff3d2a0: TAPI:OldAddTapiDevice
RegQueryValueEx(Tsp) returned 2
4294780300 PID:2ffc1bde TID:2ffe0f5e 0x8ffc19ac: >>> Loading module
ethman.dll at address 0x03C70000-0x03C77000 (RW data at
0x01FD2000-0x01FD2554)
Loaded symbols for 'C:\WINCE420\PUBLIC\SV270\RELDIR
\TRIMBLE_SHOTGUN2_SH4DEBUG\ETHMAN.DLL'
4294780366 PID:2ffc1bde TID:2ffe0f5e 0x8ffc19ac: PNP interface class
{f8a6ba98-087a-43ac-a9d8-b7f13c5bae31} (ETM1:) ATTACH
4294780394 PID:2ffc1bde TID:2ffe0f5e 0x8ffc19ac: >>> Loading module
lpcd.dll at address 0x03960000-0x0396A000 (RW data at
0x01FA3000-0x01FA3528)
Loaded symbols for 'C:\WINCE420\PUBLIC\SV270\RELDIR
\TRIMBLE_SHOTGUN2_SH4DEBUG\LPCD.DLL'
4294780401 PID:2ffc1bde TID:aff3d646 0x8ff3d2a0: TAPI:OldAddTapiDevice
RegQueryValueEx(Tsp) returned 2

etc. etc

is taking about 10 min. to complete. On another PC with CEPB freshly
installed, using the same image and connecting to the same target,
this phase takes little more than 10 sec.

We're pretty much stumped. We've tried:
- A full clean and rebuild
- Check that we've got the latest PB updates installed
- Disable of WinXP firewall and all network protocols on RNDIS
virtual network adaptor
- Uninstall/reinstall of RNDIS drivers
- Complete uninstall/reinstall of Platform Builder

all to no avail.

Can anyone shed any light on this???

Thanks

Richard.

richa...@my-deja.com

unread,
Apr 23, 2007, 8:52:28 PM4/23/07
to
Well, a complete uninstall/purge of everything CE related on my
machine followed by a reinstall seems to have "fixed" the problem

Hmmmmmm...

F.Reither

unread,
Apr 24, 2007, 5:07:31 AM4/24/07
to
Hi Richard,

we have seen similar problems. It seems that there is a correlation between
the size of the breakpoint list and
the startup speed. Removing the breakpoint list speeds up the startup of the
debug kernel.

Frank

<richa...@my-deja.com> schrieb im Newsbeitrag
news:1177375948.4...@y80g2000hsf.googlegroups.com...

Amjad (MSFT)

unread,
Apr 24, 2007, 9:45:55 PM4/24/07
to
Yes, Frank is correct. The number of breakpoints you set will have an
impact on performance especially across module (un)loads. This is because
the current implementation of breakpoint instantiation is a bit primitive in
that we try to instantiate all breakpoints on each module load. This is
something we are looking into and hope to optimize at some point in the
future.

FYI, there is a neat new capability to ignore module loads until a later
stage. Go to target->connectivity options dialog, switch to the "service
status" tab and then click "settings" for "Kernel Debugger OS Awareness".
Then switch the "Module (un)load notification to the debugger" option to
optimize this for your scenarios. This can speed up boot time as well.
Here is some help from the dialog itself:

Always off: Never catch notification, module changes are updated on each
halt. Boot time and execution is fast, real-time, but breakpoints cannot be
instantiated on time.
Always on: Catch notification of all module changes immediately. Boot time
and execution is slow, non real-time, but breakpoints can be instantiated on
time.
Off until first halt: Suppress notification until first target halt, then
catch all notifications.

--
This posting is provided "AS IS" with no warranties, and confers no rights.


"F.Reither" <rr.n...@emtrion.de> wrote in message
news:e$Fa$$khHHA...@TK2MSFTNGP03.phx.gbl...

0 new messages