none
Change Priority for explorer.exe as Shell RRS feed

  • Question

  • Is there any setting (through the registry or other means) to initialize the default shell (explorer.exe with a different priority than the default 251?

     

    Thanks.

    Tuesday, November 9, 2010 9:35 PM

All replies

  • Why would you want to do this ?
    Usually when you system shell becomes unresponsive, some OTHER application / thread is misbehaving.
    Fix the problem where it is caused.

    Messing around with priority can cause some very unexpected sideeffects. (like the sleep(0) issue)
    Dont do it when you donot exactly know what you are doing.

    Kind regards,
    Rob
    www.robtso.nl

     

     

     

    Wednesday, November 10, 2010 8:08 AM
  • On 11/9/2010 10:35 PM, TiGtMs wrote:
    > Is there any setting (through the registry or other means) to initialize
    > the default shell (explorer.exe with a different priority than the
    > default 251?
     
    You may do that by cloning the public source and adding calls to
    CeSetThreadPriority inside the threads that require highest priorities
    but, as Rob said, it's better if you give us a "big picture" overview of
    your problem because increasing priority of application threads is
    usually not a solution but a way to discover new problems...
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Wednesday, November 10, 2010 1:15 PM
  • The issue itself is that when using the CEPlayer, selecting an area in the desktop prevents the CEplayer from running.  I agree that this is not the best approach, but I know CEPlayer is not the only application getting slowed down when this selection happens outside.  I found out that the problem is a thread in explorer that is suddenly a big chunk of the CPU (even after stooping the pointer once the selection box is active); however as you mentioned, I wasn't sure of the unintended consequences of doing so.

    Also, I got an additional piece of information, and is that this doesn't happen in CE5.

    Thanks for the help.

     

    Wednesday, November 10, 2010 8:51 PM
  • On 11/10/2010 9:51 PM, TiGtMs wrote:
    > The issue itself is that when using the CEPlayer, selecting an area in
    > the desktop prevents the CEplayer from running. I agree that this is not
    > the best approach, but I know CEPlayer is not the only application
    > getting slowed down when this selection happens outside. I found out
    > that the problem is a thread in explorer that is suddenly a big chunk of
    > the CPU (even after stooping the pointer once the selection box is
    > active); however as you mentioned, I wasn't sure of the unintended
    > consequences of doing so.
    >
    > Also, I got an additional piece of information, and is that this doesn't
    > happen in CE5.
     
    Are you selecting the area on a touch screen?
    This may mean that the touch driver is sampling points inside an
    high-priority thread. Usually when you touch the screen it generates an
    interrupt but when you are keeping the finger on the display the system
    tracks finger position at an high rate.
     
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Wednesday, November 10, 2010 9:19 PM
  • The problems happens as well when using a mouse, instead of the touch pad.
    Wednesday, November 10, 2010 9:39 PM
  • I doubt that this is an Explorer Shell problem.  There is something else in your system that is blocking both Ceplayer and Explorer.  Remote Kernel Tracker would be very powerful for this, that is if the problem isn't so big that Kernel Tracker fails.
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com
    Wednesday, November 10, 2010 10:01 PM
    Moderator
  • The Kernel Tracker shows only explorer (and CEPlayer) running when the problem happens, plus killing explorer or lowering the priority allowed the other applications to run fine.
    Wednesday, November 10, 2010 11:29 PM