Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
On 5/22/26 11:34 PM, Paul wrote:
On Sat, 5/23/2026 12:49 AM, T wrote:
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
https://en.wikipedia.org/wiki/.NET
"Versioning practice
.NET Core Runtime roughly uses semantic versioning, the major.minor.patch format.
...
Patch versions are given for bug fixes, new platform support,
or other changes not included above.[37]
That means the reason for issue, may not be purely CVE based.
Paul
https://ibb.co/Pz0rNXPm
Month after month after month after ...
On Sat, 5/23/2026 12:49 AM, T wrote:
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
https://en.wikipedia.org/wiki/.NET
"Versioning practice
.NET Core Runtime roughly uses semantic versioning, the major.minor.patch format.
...
Patch versions are given for bug fixes, new platform support,
or other changes not included above.[37]
That means the reason for issue, may not be purely CVE based.
Paul
On 05/23/2026 2:34 AM, Paul wrote:.patch format.
On Sat, 5/23/2026 12:49 AM, T wrote:
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know?? Is it really such a security nightmare?
Yours in Confusion,
-T
https://en.wikipedia.org/wiki/.NET
"Versioning practice
.NET Core Runtime roughly uses semantic versioning, the major.minor
...
Patch versions are given for bug fixes, new platform support,
or other changes not included above.[37]
That means the reason for issue, may not be purely CVE based.
Paul
Not unusual for security updates, but as noted platform and code changes
are included in each and every monthly update(typically/routinely
once/mo. except in Dec.)
Also, basically a legacy product. Support ends this year. Migration to
.NET 10 is necessary to maintain the LTS(Long Term Support) path.
i.e. The customer and computer support personnel should be looking
forward rather than concern for security updates included in .NET 8.0 monthly updates.
On 5/24/26 4:12 AM, Kerr-Mudd, John wrote:
On Sat, 23 May 2026 10:22:45 -0400
"....winston" <winstonmvp@gmail.com> wrote:
On 05/23/2026 2:34 AM, Paul wrote:
On Sat, 5/23/2026 12:49 AM, T wrote:
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
https://en.wikipedia.org/wiki/.NET
"Versioning practice
.NET Core Runtime roughly uses semantic versioning, the major.minor.patch format.
...
Patch versions are given for bug fixes, new platform support,
or other changes not included above.[37]
That means the reason for issue, may not be purely CVE based.
Paul
Not unusual for security updates, but as noted platform and code changes >>> are included in each and every monthly update(typically/routinely
once/mo. except in Dec.)
Also, basically a legacy product. Support ends this year. Migration to
.NET 10 is necessary to maintain the LTS(Long Term Support) path.
i.e. The customer and computer support personnel should be looking
forward rather than concern for security updates included in .NET 8.0
monthly updates.
I spurned DotNet bloat when it first raised it's ugly MS-locked-in head.
Dot Net gives me the creeps too.
As of last week,
https://dotnet.microsoft.com/en-us/download/dotnet
M$ only listed 8 as "Long Term Support". It now lists
10 as also having long term support.
And I am not up to finding out what programs they are
running require what version of dot net. If 8 is working
for them, then that is the one to keep, until long term
support is discontinued. There is no sign of that.
******************** Scan-DotNetAssemblies.ps1 ************************
******************** END: Scan-DotNetAssemblies.ps1 ************************
On Sun, 5/24/2026 9:14 PM, Paul wrote:
******************** Scan-DotNetAssemblies.ps1 ************************
******************** END: Scan-DotNetAssemblies.ps1 ************************
Well, very funny and mostly worthless.
It claimed to find 7 files for executables.
Then it proceeded to analyze ~41000 items, which would include
some quantity of WinSxS contents.
At some point, it blew an error while trying to load an assembly.
The two output files were mostly... blank.
It did not seem to pick up my copy of paint.net freshly installed.
Paul
On 5/24/26 4:12 AM, Kerr-Mudd, John wrote:
On Sat, 23 May 2026 10:22:45 -0400
"....winston" <winstonmvp@gmail.com> wrote:
On 05/23/2026 2:34 AM, Paul wrote:
On Sat, 5/23/2026 12:49 AM, T wrote:
Hi All,
I have to do VulnDetet updates of vulnerable programs once
a week on several customers as part of PCI testing.
One customer has to get "Microsoft .NET Desktop Runtime 8",
the long term supported version, updated every month because
of some security this or that.
Is there something about Microsoft .NET Desktop Runtime 8 I
should know? Is it really such a security nightmare?
Yours in Confusion,
-T
https://en.wikipedia.org/wiki/.NET
"Versioning practice
.NET Core Runtime roughly uses semantic versioning, the
major.minor.patch format.
...
Patch versions are given for bug fixes, new platform support,
or other changes not included above.[37]
That means the reason for issue, may not be purely CVE based.
Paul
Not unusual for security updates, but as noted platform and code changes >>> are included in each and every monthly update(typically/routinely
once/mo. except in Dec.)
Also, basically a legacy product. Support ends this year. Migration to
.NET 10 is necessary to maintain the LTS(Long Term Support) path.
i.e. The customer and computer support personnel should be looking
forward rather than concern for security updates included in .NET 8.0
monthly updates.
I spurned DotNet bloat when it first raised it's ugly MS-locked-in head.
Dot Net gives me the creeps too.
As of last week,
https://dotnet.microsoft.com/en-us/download/dotnet
M$ only listed 8 as "Long Term Support". It now lists
10 as also having long term support.
And I am not up to finding out what programs they are
running require what version of dot net. If 8 is working
for them, then that is the one to keep, until long term
support is discontinued. There is no sign of that.
On 5/24/26 7:55 PM, Paul wrote:
On Sun, 5/24/2026 9:14 PM, Paul wrote:
******************** Scan-DotNetAssemblies.ps1
************************
******************** END: Scan-DotNetAssemblies.ps1
************************
Well, very funny and mostly worthless.
It claimed to find 7 files for executables.
Then it proceeded to analyze ~41000 items, which would include
some quantity of WinSxS contents.
At some point, it blew an error while trying to load an assembly.
The two output files were mostly... blank.
It did not seem to pick up my copy of paint.net freshly installed.
Paul
I use VulnDetect on my PCI SAQ-C+ customers. VulnDetect does
a good job finding dot net's.
Weird, I still find some software packages that want dot
not 3.5.
On Sun, 5/24/2026 10:55 PM, Paul wrote:
On Sun, 5/24/2026 9:14 PM, Paul wrote:
******************** Scan-DotNetAssemblies.ps1 ************************ >>
******************** END: Scan-DotNetAssemblies.ps1 ************************
Well, very funny and mostly worthless.
It claimed to find 7 files for executables.
Then it proceeded to analyze ~41000 items, which would include
some quantity of WinSxS contents.
At some point, it blew an error while trying to load an assembly.
The two output files were mostly... blank.
It did not seem to pick up my copy of paint.net freshly installed.
Paul
OK, by debugging the script, this is the type of output
it is collecting. The script is able to collect old-style information
about .NET up to maybe 4.8 or so, but not the newer stuff.
C:\Program Files\Paint.NET\System.Diagnostics.FileVersionInfo.dll
.NETFramework,Version=v4.6
This is how I modified the script, to print out some debug info to console.
Write-Host "Analyzing assemblies..." -ForegroundColor Cyan
foreach ($file in $files) {
$tfm = "" <=== clear tfm first
$tfm = Get-TargetFramework $file.FullName
Write-Output $file.FullName <=== print the filename
Write-Output $tfm <=== if there is a .NET assembly, print it
if ($tfm -and $tfm -match "=v8") { <=== The script isn't matching the right quantity...
$program = Map-ToProgram $file.FullName
$results.Add([PSCustomObject]@{
FilePath = $file.FullName
TargetFramework = $tfm
Program = $program
})
}
}
But since it does not mesh with the Core ones at all,
the effort appears useless.
CoPilot admits an extra step is required to go the extra mile.
It will take Powershell 7 to do it
"PowerShell 7 (pwsh) because EventPipe APIs are only available in .NET Core"
I got the PowerShell 7 installed, the executable was hidden in one of
those places Agent Ransack could not find it (it gets installed in an App hole).
But this script, if I watch it with Process Monitor, it's getting nowhere fast.
Just the FindNextFile loop (it is recursively walking the tree the way FindNextFile would) doesn't seem to be working as expected. It
does not finish the "Scanning C:\ for executables" section. It almost looks like an infinite loop.
*********************** Detect-DotNet8RuntimeUsage.ps1 ********************
<#
Detect-DotNet8RuntimeUsage.ps1
Scans C:\ for EXEs, launches each in suspended mode,
attaches to .NET Core runtime event stream (EventPipe),
and detects which EXEs load Microsoft.NETCore.App 8.x.
Outputs:
- DotNet8_RuntimeUsage.csv
- AccessDenied_Directories.txt
$ErrorActionPreference = "SilentlyContinue"
Write-Host "Scanning C:\ for executables..." -ForegroundColor Cyan
# --- Collect EXEs safely, capturing access-denied directories --- $accessDenied = New-Object System.Collections.Generic.List[String]
function Safe-Enumerate($path) {
try {
Get-ChildItem $path -ErrorAction Stop | ForEach-Object {
if ($_.PSIsContainer) {
Safe-Enumerate $_.FullName
} else {
if ($_.Extension -eq ".exe") {
$_
}
}
}
}
catch {
$accessDenied.Add($path)
}
}
$files = Safe-Enumerate "C:\"
Write-Host "Executables found: $($files.Count)" -ForegroundColor Green
# --- Prepare output ---
$results = New-Object System.Collections.Generic.List[Object]
# --- Function: Check if EXE loads .NET 8 ---
function Test-DotNet8Runtime($exePath) {
try {
# Start process suspended
$p = Start-Process -FilePath $exePath -PassThru -WindowStyle Hidden
Start-Sleep -Milliseconds 300
# Attach to .NET runtime event stream
$session = [System.Diagnostics.Tracing.EventPipeEventSource]::new($p.Id)
$loaded8 = $false
$session.Dynamic.All += {
param($event)
if ($event.EventName -eq "AssemblyLoad") {
$name = $event.Payload["AssemblyName"]
if ($name -match "Microsoft\.NETCore\.App.*8\.") {
$loaded8 = $true
}
}
}
# Process events briefly
$session.Process() | Out-Null
# Kill process immediately
Stop-Process -Id $p.Id -Force
return $loaded8
}
catch {
return $false
}
}
Write-Host "Analyzing runtime behavior..." -ForegroundColor Cyan
foreach ($file in $files) {
Write-Host "Checking: $($file.FullName)" -ForegroundColor DarkGray
if (Test-DotNet8Runtime $file.FullName) {
$results.Add([PSCustomObject]@{
Executable = $file.FullName
LoadsDotNet8 = $true
})
}
}
# --- Output CSV ---
$outFile = "$env:USERPROFILE\Desktop\DotNet8_RuntimeUsage.csv"
$results | Export-Csv -Path $outFile -NoTypeInformation -Encoding UTF8
# --- Output access-denied log ---
$denyFile = "$env:USERPROFILE\Desktop\AccessDenied_Directories.txt" $accessDenied | Sort-Object -Unique | Out-File $denyFile -Encoding UTF8
Write-Host ""
Write-Host "Scan complete!" -ForegroundColor Green
Write-Host "Results saved to: $outFile"
Write-Host "Access-denied directories saved to: $denyFile"
*********************** END Detect-DotNet8RuntimeUsage.ps1 ********************
I really wish I had a dollar for every bad idea... :-)
So now I can write on my resume... well no not really ?
That doesn't make me a CSharp programmer. I would get stopped
dead during The Interview, where they ask trick questions that
don't involve "Hello World".
On 2026-05-26 10:06, Paul wrote:
So now I can write on my resume... well no not really ?
That doesn't make me a CSharp programmer. I would get stopped
dead during The Interview, where they ask trick questions that
don't involve "Hello World".
:-)
However, I'm not sure such questions are still asked ... anything involving programming seems to be so badly done these days. A real world example:
Yesterday I had a really good day. Against the forecast, it was dry from the early hours, a good wind was blowing, so by afternoon my extensive areas of grass were unexpectedly dry enough to mow, and I was done by 18:00 with what I had expected to have to do today.
Following the rules of the politically incorrectly named Murphy's Law, I shouldn't've expected to be so lucky today, and so it proved. Last night, assuming that the forecast had at least a chance of being correct, I put in a whites wash (also politically incorrectly named? I'll pass on that!) to complete by 09:00. When I began to unload it, I realised that the spin cycle had apparently failed, because everything was dripping. So I stuffed the washing back in, and set a manual spin to go, and stayed to watch what happened. The drum turned over a few times in one direction only, but only clicked when it should have been turning in the other, and didn't spin.
What's this got to do with programming? This washing machine is full of sensors for temperature (it has to know when to stop heating the water), and whether the drum is still moving, etc, so it 'knows' the state of things, so why make me wait a maddening two minutes or so before I can open the door when the washing is stone cold and the drum has stopped moving?
Worse still, on this occasion the door wouldn't then open. The usual fix is to turn the machine off, wait the maddening two minutes, then turn it on for a few seconds and off again, and listen for the click of the relay as you do so. This time, nothing, nada, zilch. So then you have to turn it off again, get down on your knees (I'm in my 70s, and seized up stiff from all the exertion of yesterday), and with a screwdriver or like pull down upon a manual release mechanism. The door remained firmly closed. Eventually, realising that perhaps I'd over loaded the machine, I got it open by repeating the above, this time pushing inwards on the door. I split the load in two, and now thank heavens it's spinning. The sun is out, the wind is blowing, and hopefully all will be well.
But why make the user wait two minutes even when it's totally unjustified?
OK, to try to ensure I had a DotNet8 executable, I made my own :-)
Using Visual Studio 2022 (which still accepts the DotNet8 SDK),
I was able to write a CSharp console program. Visual Studio has
Templates for program development -- if I'd made a Windowed version,
it would add the prototype of the "Event Loop" for a windowed application. But with a console program (just runs in terminal), there is
no "glue code" needed at all. And just my luck, the Template
has the write statement for Hello World as part of the Template.
I don't even have to type that line.
I know you don't need it, but here is the result of testing
just the one directory for dotnet8 content. And I got a declaration
of True, but I haven't figured out why my attempt to debug-print
the Assembly Name, that did not work. My knowledge of Powershell,
is pretty minimal.
[Picture] Detect-One-DotNet8.gif
https://postimg.cc/ykfR6DkQ
https://imgur.com/a/apvF7z7
So now I can write on my resume... well no not really :-)
That doesn't make me a CSharp programmer. I would get stopped
dead during The Interview, where they ask trick questions that
don't involve "Hello World".
On 5/26/26 11:13 AM, Paul wrote:
That's why on the outside of the box it came in, it
says "now with extra puzzles!". You can code up some
cool puzzles for people with all this processor madness.
I don't want to brag, But I finished the puzzle in a
week and it said 2-4 years on the box.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 494928:16:17 |
| Calls: | 162 |
| Files: | 568 |
| D/L today: |
14 files (349K bytes) |
| Messages: | 74,957 |