I assume that one of the required counters is disabled.

Can you try this command (admin mode) and post the result :
lodctr.exe /Q | findstr /i "disable"

I assume that one of the required counters is disabled.

Can you try this command (admin mode) and post the result : lodctr.exe /Q | findstr /i "disable"

PS C:\> lodctr.exe /Q | findstr /i "disable"
[Lsa] Performance Counters (Disabled)
[PerfProc] Performance Counters (Disabled)
PS C:\>

So it seems something is disabled, does this include the required Process counters for the collector?

Yes, so now try to activate these counters by running the command below and check if you still have any errors.

lodctr.exe /E:Lsa
lodctr.exe /E:PerfProc

Yes, so now try to activate these counters by running the command below and check if you still have any errors.

lodctr.exe /E:Lsa
lodctr.exe /E:PerfProc

Thank you very much ❤️ @SupraOva , that does seem to do the trick. I followed those command with lodctr.exe /R , not sure if that was necessary,
but the process collector is now able to return metrics again.

Where do we go from here, I guess this should be put at least into the process collector docs?
Currently I don't have time for a quick PR, my apologies.

The setup installer cannot run this automatically, because not everybody uses the process collector though (for us, it is one of the most important ones).

Found the information there :

For backwards-compatibility reasons, the "Process" counterset returns non-unique instance names based on the EXE filename. This can cause confusing results, especially when a process with a non-unique name starts up or shuts down, as this will typically result in data glitches due to incorrect matching of instance names between samples. Consumers of the "Process" counterset must be able to tolerate these non-unique instance names and the resulting data glitches. In Windows 11 and later, you can use the Process V2 counterset to avoid this problem.

It might be interesting to use Process V2 if availeable as Process is disabled by default no?

It might be interesting to use Process V2 if availeable as Process is disabled by default no?

The issue here that windows_exporter is using Registry API that the moment which not support any V2 providers.

See also: #1350

It might be interesting to use Process V2 if availeable as Process is disabled by default no?

The issue here that windows_exporter is using Registry API that the moment which not support any V2 providers.

Ho, didn't know that, but it answers the question 😅

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

For me the above Workaround didnt fix it.
The same setup works in 2019.
I came here via grafana alloy: grafana/alloy#658

I'm currently working on a new collector which is used the windows performance data libraries. They are able to use v2 counters.

But I expect that it might take weeks develop the new feature.

Will this collector be commited to prometheus or its seperate thing?
Im Currently in the testing phase for a monitoring setup so ive some time till i need to decide on a solution.

here - #1459

The PR is not fully completed yet.

Had a similar issue on Windows 10. None of os,cpu,memory,system,logical_disk etc. worked. Another symptom was getting a "Unable to add these counters" message when starting PerfMon.

Rebuilding the counters exactly as instructed here (Administrator prompt, cd to correct directories) solved it for me.