4

I am trying to find out the Name/Value mappings of the "State" data in the message of the 'Network Connected' event log:

Path = Microsoft-Windows-NetworkProfile/Operational
Source = NetworkProfile
Event ID = 10000

So I figured I'll write a custom event log by the same provider and to the same log (path) while changing the "State" value of the message, then I can see the name mapping of that value in the event viewer.
For example, I have these Value/Name mappings so far:

1 --> 'Connected'
5 --> 'Connected, IPV4 (Local)'
9 --> 'Connected, IPV4 (Internet)'

and I want to know the rest of them.

So I tried the New-WinEvent CmdLet in PowerShell to write the logs:

New-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -Id 10000 -Payload @("SSID","Description","{B58F86AB-F35D-4F73-A41E-98EA359E1D08}",0,1,0)

And it was created, but the last 4 arguments I passed to the -Payload parameter were not taking effect. Only the {"name" = "SSID" and "Description" = "Description"} were appearing in that event. The last 4 arguments stay at fixed values no matter how I change them, while there were no errors or warnings when executing this line, neither did -Verbose show anything.

Custom Event Details

I passed these arguments (especially last 3) in all types and values available. I even passed the arguments of an earlier event log (Not logged by me) to this parameter suspecting I was mistaking the data-types but nothing changed.

$a = ((Get-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -MaxEvents 50  | Where-Object {$_.Id -eq 10000})[-1]).properties[3].value
$b = ((Get-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -MaxEvents 50  | Where-Object {$_.Id -eq 10000})[-1]).properties[4].value
$c = ((Get-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -MaxEvents 50  | Where-Object {$_.Id -eq 10000})[-1]).properties[5].value
New-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -Id 10000 -Payload @("SSID","Description","{B58F86AB-F35D-4F73-A41E-98EA359E1D08}",$a,$b,$c)

Then I tried the Write-EventLog CmdLet:

Write-EventLog -LogName "Microsoft-Windows-NetworkProfile/Operational" -Source "NetworkProfile" -EventID 10000 -EntryType Information -Message $msg -Category 0

But I kept getting the error: Write-EventLog : The source name "NetworkProfile" does not exist on computer "localhost". Although the source does exist and it's the source of the 'Network Connected' log, as you can see from the screenshot.

What am I doing wrong with these 2 CmdLets?

Liam
  • 27,717
  • 28
  • 128
  • 190
NadAlaba
  • 292
  • 3
  • 15
  • 1
    that's interesting. I see similar events in my eventlog, but then I run `[System.Diagnostics.EventLog]::SourceExists("Microsoft-Windows-NetworkProfile")` or `[System.Diagnostics.EventLog]::SourceExists("NetworkProfile")` it returns `False` – Max Feb 28 '19 at 20:42
  • 2
    Ok, I cannot make a full solution for you, but I've got where to start: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.eventing.reader.eventlogsession?view=netframework-4.7.2. It seems, that these "extended" logs are not available via "standard" API. So you need to use .Net classes (either in PS or C#). So, start with `EventLogSession eventLogSession = new EventLogSession()`, then open the NetworkProfile event provider: `System.Diagnostics.Eventing.EventProvider NetworkProfile = new System.Diagnostics.Eventing.EventProvider(Guid.Parse("fbcfac3f-8459-419f-8e48-1f0b49cdb85e"));` – Max Feb 28 '19 at 21:11
  • @Max That's odd, I thought `Write-EventLog` was built for that purpose. Anyway, I'll check how to do it with .NET, thnx! – NadAlaba Feb 28 '19 at 21:26
  • It looks like `Write-EventLog` is corresponding to `System.Diagnostics.EventLog` .Net class, which is previous generation of the API (as I can see, might be wrong). So this old-way class cannot access to the "modern" logs, thus PS commandlet too. – Max Feb 28 '19 at 21:57

1 Answers1

2

I managed to make the first CmdLet New-WinEvent work. Oddly it was a data type issue.

The 'Network Connected' event expects 6 arguments for its message. The expected types for these arguments can be seen in this Warning I got from PowerShell

WARNING: Provided payload does not match with the template that was defined for event id 1000. The defined template is following:

NetworkProfile Template

I was passing the Guid argument as a string, but it expects it to have a [System.Guid] type, and apparently New-WinEvent doesn't give warnings when you pass the 6 arguments of the -Payload parameter in an array, even if one argument doesn't have the right type. It just creates a new event with some fixed default arguments (like what was happening in my problem).

So I had to cast the right type to this argument Guid. I got the name of its type from this:

$validEvent = (Get-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -MaxEvents 500  | Where-Object {$_.Id -eq 10000} | Where-Object {$_.properties[4].Value -eq 9})[-1]
$validEvent.Properties[2].Value.GetType().FullName

Arguments Type

Then I casted the right types to the arguments and passed them to -Payload and it worked:

$name = 'SSID'
$desc = 'Description'
[System.Guid]$guid = "c48f86ab-f35d-4f73-a41e-99ea359e1d08"
[System.UInt32]$type = 1
[System.UInt32]$state = 63
[System.UInt32]$categ = 2

New-WinEvent -ProviderName Microsoft-Windows-NetworkProfile -Id 10000 -Payload @($name, $desc, $guid, $type, $state, $categ)

New-WinEvent Output

Then I could change the value of $state to get its name mapping from the $newLog.Message.

However, the second CmdLet Write-EventLog didn't work; apparently it can't write to this log by the same provider.

As Max mentioned, this CmdLet can only write to the "classic" event log, that's why it couldn't find the NetworkProfile source.

Some links that helped me along the way:

How to store an object in the Windows Event Log? [Answer] by Grady G Cooper

Writing to the event log in .NET - the right way

MSDN - Event Sources

TechNet - New-WinEvent

NadAlaba
  • 292
  • 3
  • 15
  • 1
    One thing to really bear in mind here is to get the types correct. If you use the wrong type then the entire message becomes garbled when passed to windows and you will get an error written into the XML message in windows. Tip: Pay attention to the bit length of the intergers, etc. Mixing up a 32 and 64 bit integer will break the whole message – Liam Jun 19 '19 at 14:17