WPF - Low performance when process is executed under SYSTEM account

Question

Problem Description

I have a WPF Application that is usually running under a local user account with Administrator rights. However, in certain scenarios, the process is started by a service or script that is running under SYSTEM account and the process is therefore also running under the SYSTEM account.

The issue is that when the process is running under SYSTEM account, there are some noticeable lags (the UI is not very responsive).

I did some digging using perfmon and didn't see anything suspicious (CPU is not overloaded, no unusual exceptions are thrown, no memory leaks, etc ...). I also checked the Event log and didn't find anything usefull (no Warnings / Errors, only unrelated information about the system).

I first thought it was due to the process being executed in an Impersonated context, but even without impersonation (I used PsExec.exe -i -s to start it under SYSTEM account), the lags still persists.

Any idea where this would come from ?
Do not hesitate to ask if you need more information, I'm mostly looking for some ideas that would help find the root cause (the obvious workaround for this is to not start the process under SYSTEM account but it is not really a fix).

Also, note that the application is running under a customized version of Windows Embedded Standard (XP SP3) and on a device with a capacitive touch screen.

My Question

My question is not "how can I solve this problem ?" but "why is the application running with low performance when under SYSTEM account.

Update 1

I tried to change Windows's performance optimization settings as @Sander suggested, nothing changed (http://support.microsoft.com/kb/308417).

Update 2

I also did a test using this application: http://www.kynosarges.org/WpfPerformance.html#Application
When running the app under each account, I consistently get running time about twice longer under SYSTEM account for the first GDI+ test (it basically draws a bunch of triangles), which leads me to think this is not strictly WPF limited. Again, I didn't change anything except the account under which the process is executed.

Eleusis

I know there was some "Optimize performance for a) foreground; b) background processes" setting in Windows. Perhaps it thinks that running as SYSTEM means it is a background process and therefore it de-optimizes processes under that account? Assuming it is set to prefer foreground processes. I suspect it schedules less time for the non-optimized variants. – Sprat

Does you application hit the network? Applications running under the System account may have issues accessing network resources due to Proxy settings. – Ptolemaist

@Sander: just tried to change those settings, no effect. – Eleusis

@Mark: Yes the application establishes a lot of network connections, but even when nothing is happening on the network, the application is slow. For instance, the device on which it runs has a touch screen and when pressing keys on the virtual keyboard, the visual feedback is slow (no network resources access involved here). – Eleusis

Have you profiled the application under the different accounts? Is its priority set to "normal"? – Jackscrew

@Jackscrew both yes – Eleusis

Have you tried running it under debugger and check if there are any 1st chance exceptions thrown? They may be caught later, but will slow down your application. Example: psexec -i -s windbg c:\...\youapp.exe If not then try maybe running the application under perfview (microsoft.com/en-us/download/details.aspx?id=28567) and collect some traces. You may then upload them somewhere and I will also have a look. – Caputto

I'll do that and post the results (at least what I'm allowed to) in an update 3 of my post. Thanks @lowleveldesign – Eleusis

Did you try Process Monitor to see all the file handles that are opening / closing while your application is running? Maybe you are hitting authentication timeouts somewhere: technet.microsoft.com/en-us/sysinternals/bb896645 – Expeditious

@lowleveldesign turns out that windbg and perfiew cannot run on our version Windows XP (too many required components have been stripped down). – Eleusis

@Expeditious already checked that, but it isn't the issue. As I stated in update 2, this problem also occurs with other applications (even a basic program that's just drawing triangles has the issue). – Eleusis

Have you tried System.Diagnostics.Process.Start in .net to start up the UI? msdn.microsoft.com/en-us/library/0w4h05yb(v=vs.110).aspx – Sulfonate

Yes. With the proper credentials, it starts the UI under Administrator account and fixes the problem, without credentials (when the code is executed by the service under SYSTEM), the UI is started under SYSTEM account and this is where I have the issue. My question is not "how can I solve this problem ?" but "Why is the application running with low performance when under SYSTEM account ?" – Eleusis

Wait, just to be sure... you are running it under the SYSTEM account, but not as a service, right? Also, the performance issues are related to just GDI (GUI) input/output, not actual computations? (i.e. something like superpi runs smoothly?) – Heliolatry

What happens if you run it as a different user account? I just wonder if there is some security barriers that are continually being checked if it runs under an account that is not the owner of the windows station (ie the user that's logged in), and SYSTEM is considered an account that needs these checks too. What if you run it as a different builtin account - eg LocalService or NetworkService? – Sharpset

When it is being run as SYSTEM is it being started from a scheduled task (or a process that was run from a scheduled task)? – Farro

@joshpoley No, it is started via a batch file or ProcessStartInfo. – Eleusis

@LorenzoDematté Yes, it seems to be only related to graphical stuff (GDI and WPF both have issues, havn't made other tests). SuperPI gives identitcal results under SYSTEM or Administrator account. – Eleusis

@Sharpset I cannot actually do this. The service used by runas has been removed from the OS and the only way I can reproduce the behavior is by running under SYSTEM using PSExec -i -s (using the -u and -p parameters doesn't work). – Eleusis

@CharlesAD if you can't test, then no-one can help diagnose the problem. Try running it on a different machine. We need much more info if you're going to get an answer. – Sharpset

Maybe different registry settings in the system account? Perhaps it uses software instead of hardware rendering. See msdn.microsoft.com/en-us/library/aa970912(v=vs.110).aspx – Moskowitz

Is it possible that this could be related to the Desktop Heap and Session Space? blogs.msdn.com/b/ntdebugging/archive/2007/01/04/… blogs.technet.com/b/markrussinovich/archive/2010/02/24/… – Presidentelect

@Moskowitz Just checked, hardware rendering is deactivated in both cases (it causes issues with the device's driver) – Eleusis

Answer 1

I think you should bypass the issue altogether. Don't give a system service UI, instead divide your application into two parts - one part that will perform the actual actions will run as a service (under whatever account makes sense) and the other - the UI - will run as an ordinary user process.

Use WCF to communicate between the two relatively easily.

It will solve your performance issue, as well as many potential security issues that your solution exposes.

Avid

That is already the case. The service runs under SYSTEM account and the application usually runs under Administrator, except when we have to temporarily execute it under SYSTEM account. I know the solution is to modify our code so that running it under SYSTEM is not needed, but what I'm asking is the reason why there performance issues. – Eleusis

Answer 2

When a user is logged in, most of the services in your system that are required are up and running. For example whatever you see in taskmanager and system tray.

However, when you run it from the System acc, it has to actually start some of the services that are needed in your case I am guessing it you can solve it by identifying those services and use a different thread altogether which might reduce your turn-around time.

But, the performance and CPU usage will definitely be impacted. I hope this makes sense. Thanks

Edam