Recently, I encountered a configuration file problem. Simply put, a self-developed program does not take effect after the configuration file is modified.
This problem is common for program developers and maintenance personnel for many reasons. What we want to talk about today is the reason for UAC.
The situation mentioned at the beginning of this article is as follows: the programs developed by our project team originally run on Windows 2003 and recently intend to migrate to Windows 2008. One day, after logging on as a non-administrator user (still in the Administrators group), I used notepad to modify the configuration file of the EXE file. After double-clicking the file, the changed configuration did not take effect; however, when I right click "Run as administrator" on the EXE, the changed configuration takes effect.
This strange phenomenon cannot be avoided. The reason for UAC is not clear after you check the information.
The simple solution to the above problem is to "run as administrator", which is a little more complicated to operate; or To disable UAC, but it is not necessary to sacrifice system security.
More effective methods are complex. You need to understand all aspects of UAC. Here is a list of materials for your reference:
- What Windows user accounts Control
- Learn more about Windows Vista User Account Control