Delphi demands elevation?

[Bill Meyer 337]

I am working on a large project in Delphi 10.2. Friday all was well. Yesterday morning, I found that I could not run the app in the IDE but received a message that a process needed to be elevated.

I have checked settings everywhere, I think. I've reverted to code from last Thursday, and the problem persists. However, the issue, whatever it is, is in the VM, as I carried this VM from my home machine to the office, and I see the problem here, as well.

EurekaLog makes no report if it. I tried MadExcept, which is not my usual too, and it does report, but what it is telling me is not obvious to me. The most meaningful content in the fairly long report appears to be this:
disassembling:
[...]
203b5baa         call    -$548a7 ($20361308)    ; System.LoadResString (dbkdebugide250.bpl)
203b5baa
203b5baf         mov     eax, [ebp-$64]
203b5bb2         push    eax
203b5bb3         mov     eax, [ebp+$20]
203b5bb6         mov     [ebp-$5c], eax
203b5bb9         mov     byte ptr [ebp-$58], $11
203b5bbd         lea     edx, [ebp-$5c]
203b5bc0         xor     ecx, ecx
203b5bc2         pop     eax
203b5bc3         call    -$52938 ($20363290)    ; Winapi.PsAPI.System.SysUtils.Format (dbkdebugide250.bpl)
203b5bc3
203b5bc8       loc_203b5bc8:
203b5bc8 05481   mov     ecx, [ebp-4]
203b5bcb         mov     dl, 1
203b5bcd         mov     eax, [$203687f0]       ; Dbkhelper.EDbkError.Create (dbkdebugide250.bpl)
203b5bd2         call    -$5291f ($203632b8)    ; Winapi.PsAPI.System.SysUtils.Exception.Create (dbkdebugide250.bpl)
203b5bd2
203b5bd7         call    -$54af4 ($203610e8)    ; System.@RaiseExcept (dbkdebugide250.bpl)
203b5bd7
203b5bdc       loc_203b5bdc:
203b5bdc 05483 > mov     eax, ebx
203b5bde         call    -$4d067 ($20368b7c)    ; Dbkhelper.CheckRetVal (dbkdebugide250.bpl)
203b5bde
203b5be3 05484   xor     eax, eax
203b5be5         pop     edx
203b5be6         pop     ecx
203b5be7         pop     ecx
203b5be8         mov     fs:[eax], edx
203b5beb         push    $203b5c64
203b5bf0         lea     eax, [ebp-$64]
203b5bf3         mov     edx, 2
203b5bf8         call    -$54acd ($20361130)    ; System.@UStrArrayClr (dbkdebugide250.bpl)
203b5bf8
203b5bfd         lea     eax, [ebp-$54]
203b5c00         call    -$5496d ($20361298)    ; System.@IntfClear (dbkdebugide250.bpl)
203b5c00
203b5c05         lea     eax, [ebp-$50]
203b5c08         call    -$54aed ($20361120)    ; System.@UStrClr (dbkdebugide250.bpl)
203b5c08
203b5c0d         lea     eax, [ebp-$4c]
[...]

If I run Delphi as Administrator, it all works. If I run the executable outside the IDE, it works without complaint. So the complaint seems to me to be related to the debugger, but I have not been able to discover what might affect it.

Would appreciate any insights.

[Guest]

Few things about the above

1) Stack will be more helpful than disassembly.

2) You didn't clear which is in the VM, talking about the built EXE and the IDE ? is it both or one, my thought is that only one in the VM and the other is on your different devices.

3) You didn't mentioned what if the IDE ran with administrator privileges and tried to debug, what is the error and the more important questions, does the IDE see the EXE at all ?

 

The above points will help and if i to guess, the problem is coming from one of them (IDE and EXE) does have different and/or more restrictive user ownership and access, the easiest way to fix this is to take ownership and/or to add user privileges (something like everyone will do for exe but not for the IDE's if they are outside the VM), and that depends on which is coming form different machine.

 

 

You asked for insights, and hope this give you a line to follow, the thing with user privileges is that they are very tricky and you need to understand the problem to solve it on all your devices.

 

ps: when handling security for files, be careful and check folders, some folders might have different security settings, so if you to check then files and folders, also sometimes just deleting files is not enough and you need to delete their folders to create new ones with current user privileges.

 

[Der schöne Günther 316]

I might be missing something, but I think your topic title is misleading. An application "demands" elevation if it does so through its manifest or Windows thinks it should have elevation (for example, when it's named "setup.exe"). In your case, it's "I get a runtime exception when the app is not elevated. When it is, it appears to be fine".

 

PS: I think the Windows "Sandbox" is a nice feature to check something out on a fresh installation. No need to roll back virtual machines.

Edited June 9, 2021 by Der schöne Günther

[Guest]

56 minutes ago, Der schöne Günther said:

I might be missing something

I might be wrong but you might not have clear picture on how security and privileges work on Windows, it is very complicated subject and easy to miss as we rarely face such situations.

 

So let me explain few things, while i can't cover it at all, i will miss mentioning many facts, also there is many sources in the internet explain this better than me, the Microsoft documentation is not clear enough for first reading, but i hope after this you can understand these resources better.

 

Inheritance, (damn it, it took me while to remember the word), security inheritance is where things get complicated and cause confusion, see if you are logged to your Windows as ABC then used the Notepad to create a file 1.txt that file will have same security and ownership inherited from the user ran Notepad not the one created Notpade.exe !, that one is important thing to remember.

Also when you opened save dialog and created a folder to save the file within, that folder will have the same process security coming from runtime usage, that another important thing to remember, because it might cause confusion when creating folder or a file from within aopen/save dialog this belongs to that process and its user security, not Windows Explorer and the logged user !.

 

Another thing is if you are using RDP and created a file that file will use your security privileges, the file will eventually will have the logged user from the RDP, means a remote user on the server, the one logged in.

the thing get complicated when you use network share or RDP shared resources, as these different situations, the RDP shared resource will insure your local file security and users privileges will be still the same on the remote device, and here comes the problems, i am using this example to explain how things can go south easily, your uploaded file have ownership of the creator which is ABC (its you from your PC) and it will still have ABC on the remote, so if different user logged using RDP there is a big chance that he might see the file but can't open it !, unless your privileges allow users or everyone or explicitly declare the other users by name.

 

Now to the debugging privileges, a debugger doesn't need an administrator privileges per se to run and debug, but it definitely require privileges enough to debug the executable in question while have the privileges to debug, i hope that is clear, so the a debugger to debug need privileges by its own and the debugged file should be in compliance with that, only then you can debug.

 

I hope this does clear why i asked where the IDE and files ( executables and folders) did come from ? and who was the user who create each of them ?

[Bill Meyer 337]

I will try to clear up the issues which I failed to adequately explain in my original post. The complete report from MadExcept is here: https://pastebin.com/rS7vn8Tc

1. Everything in my note is based on the content of the VM. The IDE is there, and when I run independent of the IDE, the app is also running in the VM.
2. Running the IDE normally, the error I get is this: 
 
  That error occurs before I reach the first line in the DPR.
3. Running the IDE elevated,  there is no error.
4. We use a manifest, and it does NOT specify elevation in privileges.
5. I said the application "demands" elevation because without elevation, I cannot get to any part of the application code in debug mode. Oh, and running in the IDE without debugging fails in exactly the same way.
6. RDP is not involved; I am running the VM on my local machine.
7. The project has been migrated from D2007, though some files also came from XE7. Migratory work was completed months ago. We are now in debug and functional rework.
8. I created the VM and did the initial work migrating components and application code. The VM has been in use for 10+ months with no issue of this sort until two days ago.
9. As I mentioned in my original post, reverting to code from last Friday does not alter the behavior. Neither does code from two weeks ago. So again, the behavior is contained in the VM image in some way, but is independent of application code.
10. I am the only developer experiencing the elevation error. My colleagues do not get the error.
 

I do appreciate the thoughtful suggestions and the insights into security in Windows. However, from Friday afternoon to Monday morning, something changed which created the need for elevation. No files were added or altered in that interval. I have pored over settings to no avail, and am at a loss to imagine what Delphi option, either global or project level, could create this issue, or why.

 

At this point, I am wondering about the registry, about security policies (none of which I have altered), and beyond those thoughts, I am out of ideas, other than to build a new VM from scratch.

Edited June 9, 2021 by Bill Meyer

[timfrost 78]

If you right-click the EXE and select Properties/Compatibility, is 'Run as administrator' checked?  This setting would survive rebuilding and would also be unique to your own VM where it is running, as well as independent of the manifest it contains.

[Bill Meyer 337]

1 minute ago, timfrost said:

If you right-click the EXE and select Properties/Compatibility, is 'Run as administrator' checked?  This setting would survive rebuilding and would also be unique to your own VM where it is running, as well as independent of the manifest it contains.

As I mentioned above, I have run normally as well as elevated (Administrator), and although 'Run as Administrator' allows me to work, it is abnormal, and not the desired mode of operation.

[Bill Meyer 337]

Dalija Prasnikar pointed out https://quality.embarcadero.com/browse/RSP-34143, which is for Rio and 64-bit, but otherwise vary similar:

Debugger stops with 'Cannot create process'
The executables run fine when started from Explorer.
Uninstalling the update solves the problem.
32bit debugger is fine.

[Bill Meyer 337]

OK, this is back again. Went through this sequence of actions:

Debugging code, find error

Exit app

Modify code

Rebuild and run

Throws error:

 

Did some searching, found this an article on StackOverflow which led me to rename the project and rebuild. That one change let me debug again, but if I revert to the original name, the error is back.

 

The persistence linked to the name makes me suspect something in the registry, but searching there has so far turned up nothing useful.

 

Last time I went through this, I abandoned my VM and used a backup. Since this now seems likely to occur again, I really would like to find a way to identify the mechanism behind it. Any suggestions would be most welcome.

 

[Remy Lebeau 1394]

7 minutes ago, Bill Meyer said:

Did some searching, found this an article on StackOverflow which led me to rename the project and rebuild. That one change let me debug again, but if I revert to the original name, the error is back.

 

The persistence linked to the name makes me suspect something in the registry, but searching there has so far turned up nothing useful.

What is the actual project name?  Sounds like UAC's "Installer Detection" feature kicking in.  You absolutely should have a UAC manifest in the project to avoid that, not relying on the persistence of the "Run as Administrator" option on the EXE properties.

[Bill Meyer 337]

20 minutes ago, Remy Lebeau said:

What is the actual project name?  Sounds like UAC's "Installer Detection" feature kicking in.  You absolutely should have a UAC manifest in the project to avoid that, not relying on the persistence of the "Run as Administrator" option on the EXE properties.

Sorry, should have said. It is MediaOffice.exe. So unless they "detect" based on the name containing "office", I am at a loss. 

 

Also bear in mind that this has worked for months, with that name. Then in June, suddenly, the elevation error occurred. Switched to a backup VM, and had been fine again until yesterday, when suddenly the problem was back. I had pulled no updates, and made no changes at project level. The changes between builds were limited to code in an Excel export module. The error occurs, however, before we reach the first line of code in the DPR. And there are no initialization sections in the project. None, zip, zero.

Edited August 17, 2021 by Bill Meyer

[Remy Lebeau 1394]

1 hour ago, Bill Meyer said:

Sorry, should have said. It is MediaOffice.exe. So unless they "detect" based on the name containing "office", I am at a loss. 

The Installer Detector looks at a lot of different things, not just the filename:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc709628(v=ws.10)

Quote

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords like "install," "setup," "update," etc.
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

1 hour ago, Bill Meyer said:

Also bear in mind that this has worked for months, with that name. Then in June, suddenly, the elevation error occurred. Switched to a backup VM, and had been fine again until yesterday, when suddenly the problem was back. I had pulled no updates, and made no changes at project level. The changes between builds were limited to code in an Excel export module.

Hmm...

1 hour ago, Bill Meyer said:

The error occurs, however, before we reach the first line of code in the DPR. And there are no initialization sections in the project. None, zip, zero.

Right, because the Elevation error occurs while the process is being created, before it starts executing.