none
System Crashes When Using CETSC RRS feed

  • Question

  • Hello,

    I'm running Windows Embedded CE 6.0 R3 with all monthly product update rollups until June 2010 on an AT91SAM9263-based device. My OS design includes the Terminal Services Client for Windows CE (CETSC), which I'm using to connect to a server running Windows Server 2008.

    I have no problem establishing a connection to the server and starting a remote application, but after some time of work with the remote application the CETSC freezes and the whole CE system seems to crash. The time intervals from CETSC start to the point, when the system becomes unusable, range from a few seconds to a few minutes.

    When I analyzed the output of the system on the serial debug interface (DBGU), I found some entries resulting from data abort exceptions. These data abort exceptions have their origin in some Microsoft code linked into the graphics driver for my device. Some exceptions are caused by dereferencing the pointer "pwT" on line 72 of file "%WINCEROOT\public\common\oak\drivers\display\emulrotate\ebFill16.cpp". This pointer contains the value NULL from time to time. Others are caused by misaligned integer accesses to memory addresses stored in "src.Ptr" on line 717 of file "%WINCEROOT\WINCE600\public\common\oak\drivers\display\gpe\swblt.cpp".

    I have figured out that such an exception occurs whenever I open a pop down menu in the remote application via its menu bar. Although not every exception leads to a system crash, there is always one exception immediately preceding a crash.

    Maybe someone has experienced the same problem using CETSC and can give me a hint on how to solve it.

    Best regards,

    Martin
    Friday, November 12, 2010 10:32 AM

All replies

  • Hi Martin,

    are you using the Atmel AT91SAM9263 processor based board with your own BSP or with Atmel-provided BSP 1.0.3.B ? If the second answer is right, then did you ever try to run CETK tests for display driver on your platform ? These CETK tests may tell you more about specific failures in display driver, compared to just failures in terminal server connection sessions.

    Hope this helps

    SergeiR

     

    Monday, November 15, 2010 8:11 AM
  • Hi SergeiR,

    I'm using the Atmel-provided BSP v1.3.0B, and I didn't run CETK tests for the display driver.

    Thank you for your hint, I will run the tests as soon as possible and report back about my findings.

    Regards,

    Martin

    Monday, November 15, 2010 9:32 AM
  • Hi,

     

    I ran the GDI tests from CETK and one test failed. It's the test named "GradientFill" (test ID 222). I'm still wondering what this means for my problem ...

     

    Regards,

    Martin

    Monday, November 22, 2010 5:28 PM
  • Hi Martin,

    thank you for the update on CETK test results on Atmel AT91SAM9263 platform. The failures in GradientFIll CETK test should not result in data aborts at run time in my opinion. On the other hand, if your platform does not include Gradient Fill option in PB Catalog, then this failure may be acceptable.

    A few things you can try though. When creating a RDP connection to a remote computer from your CETSC-enabled Atmel platform, try modify CETSC settings before opening such connection, such as color depth or some other options such as displaying background. For example set color depth to 256-color, save settings, then try your connection to a remote machine with that drop down bar to cause an exception. Then try 16-bit color and finally 24-bit color is available.

    Also the fact that you see this file "%WINCEROOT\public\common\oak\drivers\display\emulrotate\ebFill16.cpp" pointed to at the moment of exception may suggest another test : are you running rotated display ? Maybe try a different orientation of disply with your test ? Also maybe rebuid Atmel platform with a rotation option disabled for a display driver ?

    Hope this helps

    SergeiR

     

     

    Wednesday, November 24, 2010 9:34 PM