No Applications in your home directory
Your home directory is not a place for applications, they should not be in there.
Malware may store itself there and will try to run from there. So prevent that.
Open an elevated PowerShell and run:
icacls $env:SystemDrive\users\username /deny "username:(OI)(IO)(X)"
to undo this change:
icacls.exe $env:SystemDrive\users\username /remove:d username
The standard Chrome install puts itself into the user's home directory, this no longer works.
Use the Enterprise installer
instead and install it for everybody.
The wonderful Process explorer has a single file with both the 32bit and 64bit versions in it, on a 64bit OS, it extracts the 64bit version to %TEMP% which is %USERPROFILE%\AppData\Local\Temp and then tries to start it from there.
This is no longer works. Just copy the file Procexp64.exe into your tools folder and run it from there.
All portableApps.com apps create a ramdom folder in the user's temp directory and then copy and use two dlls in there. This does not work and you get an incorrect message:
Another instance of ... is starting. Please wait for it to start before launching it again
Because it is a random name, I don't know how to handle this.
My current work around is to use a second user that runs all the portable apps.
nUnit bails out
nUnit copies the assembly to be testing into the user's temp directory and then tries to run it from there.
Open the file:
Set the value for the ShadowCopyPath to a location where you can both write and execute but away from your home directory:
<Setting name="Options.TestLoader.ShadowCopyPath" value="X:\dev\temp" />
Updating Firefox failed???
It also copies itself to the AppData\Local\Temp and fails:
DismHostLib: Failed to create dismhost.exe servicing process.
Developing Windows Phone Apps
Using Visual Studio to develope Windows phone and most likely other modern Windows Apps fails. It creates the app in the users home directory. Even loading a XAML page in the designer in Visual Studio fails with an error: E_ACCESSDENIED (0x80070005). It tries to run XDesProc.exe in a random directory. Running Visual Studio under my secondary account fails in the same way. But logging on with that account and then starting Visual Studio works.
Running any LibreOffice program prompts with the interesting message box:
LibreOffice requires Windows or later. This PC is running Windows ?, so LibreOffice can not be started
For now I'm using my secondary user to start LibreOffice on my unsupported Windows system.