An update on this issue.
Toys" package that RPM comes with) is not supported by Microsoft. So
"WilS" <wstarknospam04@pobox.com> wrote in message
news:euGiCcjqIHA.1736@TK2MSFTNGP04.phx.gbl...
>I have a generic WinCE 5.0 system (desktop, shell, etc). When I try to use
>the Remote Performance Monitor tool that comes with the
>NETCFv35PowerToys.msi, it crashes when I hit the 'GC Heap' button.
>
> To reproduce, I can generate an "out of the box" wizard generated C# app
> targeting .NET CF 3.5 using VS2008. I change the generated Program.cs
> file to be:
>
> using System;
> using System.Linq;
> using System.Collections.Generic;
> using System.Windows.Forms;
> using System.IO.Ports;
> using System.Threading;
>
> namespace TestRPMTools // your namespace here...
> {
> class Program
> {
> static SerialPort m_SerialPort;
>
> /// <summary>
> /// The main entry point for the application.
> /// </summary>
> [MTAThread]
> static void Main()
> {
> m_SerialPort = new System.IO.Ports.SerialPort("COM4", 115200,
> Parity.None, 8, StopBits.One);
> m_SerialPort.Open();
> Application.Run(new Form1());
> m_SerialPort.Close();
> }
> }
> }
>
> Now, just run this program on the target (using the RPM tool), and start
> hitting the GC Heap button. Sometimes it works a few times (close GC Heap
> window without saving if this works), but after a few times it fails,
> throwing up a message box with this text:
>
> exception code: 0xC0000005
> exception address: 0x01d3a39c
> Reading: 0x00000300
> Faulting Module: mscoree3_5.dll
> Offset: 0x0008a39c
>
> Does anyone have a suggestions at all as to how to attack this issue? Is
> this likely to be a bug in mscoree3_5.dll? Is there something that I need
> to be sure is in my WinCE nk.bin image? (Right now, .NET CF 3.5 is
> deployed by VS2008 - it is not built into the nk.bin image. I have pretty
> up-to-date QFEs in the nk.bin.)
>
> Full Disclosure: Also, the above code with the serial port is something
> that I reduced my program to in order to report this issue. But removing
> the same code from my larger program where the issue was first discovered
> doesn't fix the issue, so the above code may be a red herring. The crash
> may be caused by some unrelated issue.
>
> (
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=331277)
>
> Thanks for any suggestions anyone might have!
>
> - Wil
>