remote desktop slow start on XPE

  • Thread starter Thread starter me
  • Start date Start date
M

me

We have a small problem with windows XP embedded. When you first boot it
up, if you try to connect to it using remote desktop the logon screen
can take up to a minute to come up. We have tried making every service
we can possible think of be auto start, we added more ram, etc, nothing
seems to help. So then I tried a small hack, when the machine first
boots up we fake RDP into it until the logon screen comes up then when a
user actually wants to use it the logon screen comes up right away. This
works great for a few minutes (dont know how long) then the logon screen
starts taking as long as it used to. Any ideas what might be causing this?
 
Is the problem reproducible locally on the device? (I mean if you logon locally but not remotely over RDP)

Do you have a Processor component in your configuration that matches hardware?

Does the device log in a domain? Is English Language based image or not?

Try to monitor the boot and logon with BootVis tool.
 
KM said:
Is the problem reproducible locally on the device? (I mean if you logon locally but not remotely over RDP)

Do you have a Processor component in your configuration that matches hardware?

Does the device log in a domain? Is English Language based image or not?

Try to monitor the boot and logon with BootVis tool.
Click to expand...


The problem happens both locally and remote. I will check the processor
but im pretty sure thats correct. Iits not part of a domain and its all
in english.
Its almost like if some "service" was not started until you first try to
use remote desktop.
 
I've also seen this in both the Pro and Embedded world when using RDP,
but only at boot up. Are you using the Windows Firewall and are you
running XPe SP1 or SP2?
 
Do you see anything meaning in Event Logs? Basically if it would be a service start problem you might see something like "...
service was not started. Starting ... service.".

Again, if the problem was easy to repro locally I'd recommend to try BootVis.
 
The Event Log doesn't always seem to catch the failure of a service at
start up. BootVis didn't provide me with anything useful on my
deployed box and crashed on my development machine. Any other
suggestions?
 
Dwayne,

Not really. I mean the only possible way I see to figure that out would be either using KD (debugging) or Regmon/Filemon during the
first RDP connection or local logon.
Pretty laborious, though.
 
KM said:
Dwayne,

Not really. I mean the only possible way I see to figure that out would be either using KD (debugging) or Regmon/Filemon during the
first RDP connection or local logon.
Pretty laborious, though.
Click to expand...

Thats where we are at, nothing has helped. What is really wierd for us
is that after a while (maybe 30 minutes or more) the RDP logon screen
starts taking a long time again, so its like if some service is woken
up, and hten a few minutes later it goes to sleep again.
 
Wow that is bad. Here I was complaining about a 2-3 minute wait for
the RD login. Is the Remote Procedure Call service set to start
Automatically on your system? Are you connecting over Wired network or
Wireless? Have you tried deselecting the QoS Packet Scheduler and/or
the File and Printer Sharing for Microsoft Networks under the network
properties of the device?

Does your device obtain it's IP address dynamically or statically? If
dynamically, try setting a static IP address and see if you get the
same delay.

I hope some of my suggestions help.
 
Dwayne said:
Wow that is bad. Here I was complaining about a 2-3 minute wait for
the RD login. Is the Remote Procedure Call service set to start
Automatically on your system? Are you connecting over Wired network or
Wireless? Have you tried deselecting the QoS Packet Scheduler and/or
the File and Printer Sharing for Microsoft Networks under the network
properties of the device?

Does your device obtain it's IP address dynamically or statically? If
dynamically, try setting a static IP address and see if you get the
same delay.

I hope some of my suggestions help.
Click to expand...

I will try the file printer sharing and QoS stuff, thats the only thing
we havent tried :-(
 
Back
Top