From time to time, I get an email about Standard User Analyzer that includes a screenshot or a MessageBox text copy (you do know you can control-c a MessageBox and paste just the text, right?) that looks something like this:
Failed to load log file c:\Users\<user name>\AppData\Local\Temp\1\sua: No (valid) log file is found.
It typically is reported by people running Windows Server 2008 or Windows Server 2008 R2. What’s going on?
It turns out that it’s caused by a group policy setting enabled for Terminal Services: Do not use temporary folders per session.
Now, “session” is an unfortunately overloaded term in Windows. There is an LSA Logon Session, and there is a Remote Desktop Session (formerly known as Terminal Services Session). When you log on as a protected administrator (a member of the local administrators group with UAC enabled), you generate two LSA Logon Sessions – one for your filtered token, and one for your full token. However, you live in one Remote Desktop Session. So, it’s legitimately a bug that we’re popping over to a different temp directory for one of your tokens.
However, it’s a bug we’re not going to close at the moment, for application compatibility reasons. This bug has existed since Windows Vista, and those who have come across it have implemented workarounds – workarounds it turns out we break if we fix the bug.
App compat is one of those weird realms for engineers. If we fix bugs, we break apps, and people are unhappy. If we don’t fix bugs, then we still have bugs, and people are unhappy. That’s why we come up with features like SwitchBack and Shims – so new apps can get bug fixes, but old apps continue to get bugs. But it’s hard to always do that perfectly, particularly mid-stream.
So, what do you do to get SUA running? It turns out that you have a couple of workarounds:
Hopefully that gets some of you back up and removing admin dependencies.
Preemptive snarky comment: You can also just use LUA Buglight as a workaround. :-)