C# EventLog.Delete Access Denied

Question

I have read other questions on SO in regards to security and registry keys, nothing has helped me solve my particular use case scenario.

Here's my scenario:

What I'm Trying To Do

I want to, in code, delete a windows event log.

The Problem

When executing the function, I receive a System.ComponentModel.Win32Exception. The exception message is "Access is denied".

How I Am Doing It Currently

I am using an impersonator function that I wrote which wraps around the EventLog.Delete function, it drops me into a user context that has full access to the EventLog Registry Hive. Subsequently the logs I am interested in also have full access for this particular user.

My Question

Why do I receive a "Access Is Denied" if the user I am running under (through impersonation) has full access to the log in question? I've tested my Impersonation function and it works as expected for other code I've written. I don't get why I would get access denied for this.

In another scenario with my impersonation function it works just fine, for example if I tried to write to a file that the user context that is running the program does not have write access to, then I would not be able to write to the text file, however if I use my impersonation to drop into a user context that does have write access then it works just fine (I can write to the file). So I just don't understand why the same concept can't be applied to registry keys.

What am I missing here?

The Code

1. Exception Message

2. My Test

Where sw-test is a user I created for testing purposes, it has full access permissions to the registry we are trying to delete.

        [TestMethod]
        public void DeleteEventLog_ValidatedUser_DeleteLog()
        {
            using (new Impersonator(Environment.UserDomainName, "sw-test", "pswd"))
            {
                Logging logging = new Logging();
                logging.DeleteEventLog("testLog");
            }
        }

Answer 1

Okay I eventually got around to figuring this out, there were two issues at play here that were causing the mentioned exception being thrown, they are as follows:

1. Visual Studio was NOT running in administrator mode.

Not running visual studio in administrator mode was one part of the problem, this seems to be associated with access tokens in the windows OS. According to a source I read, if I run a program without UAC on (which is my scenario, I have it off), then the program being run gets a copy of my access token. However if I have UAC enabled, the program gets a copy of my access token but it is a restricted access token. (see: What precisely does 'Run as administrator' do? ) - To be honest this doesn't really make sense in my case, why do I have to run as admin if I have UAC off? Shouldn't visual studio have an unrestricted copy of my access token? I am in the administrator group with UAC off...

2. Not Specifying NewCredentials As a Logon32Type In Impersonation

I don't really understand it but as soon as I specified this for my impersonation everything started working perfectly, I read a blog about it, it talks about how it was introduced in the VISTA days and how it was mainly used to specify credentials to outbound network connections to servers, and was mainly used to remedy security-related issues server-side. Don't see how it correlates to interfacing with local event logs though. (see: https://blogs.msdn.microsoft.com/winsdk/2015/08/25/logonuser-logon32_logon_new_credentials-what-is-this-flag-used-for/ )

Code

            using (new Impersonator(Environment.UserDomainName, "sw-test", "pswd", Advapi32.Logon32Type.NewCredentials))
            {
                EventLog.CreateEventSource("testSource", "testLog");
                EventLog.Delete("testLog");
            }

Where the NewCredentials is an int 9