Fatal error (Invalid class)

[lmaoezcode]

2024-01-16_11h15m31s_Runtime.log

Just click on the icon on desktop, but this window appeared, and nothing happened
I read some previous topic, and I tried to fix my WMI, but my SEB are still not working

I'm using:

• OS: Win 10 ver 22H2
• SEB newest version (3.7.1): https://sourceforge.net/projects/seb/files/seb/SEB_3.7.1/SEB_3.7.1.704_SetupBundle.exe/download

Is there any thing I could do to fix it myself:(((

[pholfeldUMA]

Since I was tasked to report the same issue, I will join this conversation.

It seems last week during exams, 2 students out of roughly 300, reported the same error.
In one of the cases I was able to confirm, that the student's WMI repository did not show as corrupted.
Sadly, I was in no position to get my hands on the log files.

[dbuechel]

There really isn't anything we can do at all here. Most users were able to resolve the issue by either fixing the WMI repository or reinstalling their system. The latter is obviously a last measure, but a computer system simply must have a valid network adapter configuration accessible via WMI in order for SEB to be able to function correctly.

[dbuechel]

Thus, unless there is a way to reliably reproduce the issue on our side, there is nothing we can do here.

[strau0106]

I have a lot of devices reliably producing this error when not connected to the internet on SEB 3.7.1.

Checking the relevant code you seem to have tried to account for this issue but the stacktrace makes it evident that the try except does not work in InitializeMacAddress in SystemInfo? LINQ deffered execution being a PITA once again? My guess based on my somewhat limited C# knowledge would be that the LINQ code to get "MacAddress" would only be actually executed once in the finally... but I can be wrong

I know the scope of this issue is very limited but still a crash like this isn't very nice...

[dbuechel]

We currently do not catch any exceptions related to the MAC address initialization (the finally block just makes sure that in all cases, it is never null). At the moment, we depend on a valid MAC address for some functionality and it would be expected that most systems should have a network card with a valid MAC address, regardless of whether they're connected to a network or not.

Having said that, the last sentence is likely where the issue arises: The WMI query used most likely does not work (at all or always) for systems which (momentarily) do not have a network connection. We shall track this issue and certainly attempt to improve it under #966.

The other issue with the error message "invalid class" is however still not reproducible for us, so we'd need a way to reproduce it in order to attempt to fix it as well.

[github-actions]

This issue is stale because it has been open for 28 days with no activity. It will soon be closed automatically if there are no updates.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.