SMBIOS Explorer

[Ghostwalker]

Endlich ist (das gröbste) geschafft.

Ich möchte euch hier den SMBIOS Explorer vorstellen. Das Programm analysiert den SMBIOS-Block im Rombios um die dort gespeicherten
Informationen anzuzeigen.

Bis auf Type31 und Type40-Blöcke werden alle SMBIOS-Strukturen gelesen.

Historie

- 26.05.2008 Erste release
- 09.06.2008 Erste Screenshots der Version 2.0

- Überarbeitete SMBIOS-Bibleothek
- Conformance-Check mit den Spezifikationen 2.3.2 und 2.6
- Neue Oberfläche
- SMBIOS-Strukturen 31 und 40
- Mehrsprachigkeit
- JEDEC-Hersteller (soweit verfügbar).
- Verbessertes Fehlerhandling.


- 23.06.2008 Beta 1

Features siehe 09.06. :)


Basis des Programms ist auch hier wieder NicoDE's Rombios-Dump Unit :)

Anregungen, Fehlermeldungen sind natürlich gerne gesehen :)

[EDIT]09.06.2008
Ich werde versuchen noch heute eine ersta Alpha online zu stellen, in der die meisten
neuen Featueres enthalten sind.[/EDIT].

[DevidEspenschied]

Dein Programm ist ganz nett, aber noch ausbaufähig. Leider fehlt die Info, welche DMI-Strukturen denn überhaupt unterstützt werden. Interessant wäre bspw. der Typ 15 des Event Logs, da dies der komplexeste Typ mit den meisten Möglichkeiten ist.

Zur Info: hier gibt es bereits eine kommerzielle Lösung, die eigentlich fast keine Möglichkeiten offenlässt.

[Ghostwalker]

Bis auf Type31 und Type40 werden alle Strukturen gelesen (Info im 1. Post ergänzt).

Im Gegensatz zu der kommerziellen Lösung, hole ich die Infos nicht über die Ports sonder über einen Memorydump des Rombios. Dadurch entstehen natürlich einige Nachteile, besonders was Laufzeit-Informationen betrifft.

Das Hauptaugenmerk bei diesem Projekt liegt mehr auf den statischen Informationen, weniger auf den dynamischen :)

[DevidEspenschied]

Die DMI-Attribute, welche dynamisch aktualisiert werden, kann man ja mit einem aktualisierten Dump auslesen. Nach meinen Informationen dürfte es sich dabei um sehr wenige Attribute handeln.

Der Vorteil Deiner Nicht-Port-Lösung besteht ganz einfach darin, dass Du keinen Gerätetreiber für den Portzugriff brauchst. Admin-Rechte sind aber lt. meinen Infos trotzdem notwendig, und das würde ich per Manifest einbauen. Wie verhält sich das Programm unter Vista, wenn es ohne Admin-Rechte gestartet wird ?

Ansonsten noch 2 Erweiterungsvorschläge:

1. Im rechten Bereich würde ich eine Art Karteireitersystem hinzufügen, in dem zwischen der bisherigen Ansicht sowie den reinen Datendumps, etwa per Byte, Word oder LongWord unterschieden werden kann. Siehe hierfür die Darstellung in der kommerziellen Lösung.

2. Falls Du dich mit Deiner Lösung etwas abgrenzen möchtest, bietet die SMBIOS-Spezifikation im Anhang A die sog. Conformance Guidelines, welche definieren, welche DMI-Felder und Strukturvorgaben für eine korrekte DMI-Spezifikation vorhanden bzw. erfüllt sein müssen. Daraus kann man eine DMI-Diagnose basteln, welche den DMI-Bereich konsequent nach diesen Vorgaben prüft. Meine Erfahrung hat hier gezeigt, dass die meisten Systeme diesen Test nicht bestehen, da die Mainboardhersteller nicht alle und zum Teil falsche Informationen eintragen. HP und Fujitsu-Siemens hingegen haben weitestgehend korrekte DMI-Bereiche in Ihren Komplettsystemen.

Ich weiss nun aber nicht, ob sich dieser Aufwand überhaupt für Dich lohnt und wie weit Du mit Deiner Lösung eigentlich vorankommen möchtest...

[Ghostwalker]

Was die Admin-Rechte mit Vista betrifft, kann ich keine Aussage treffen, da ich kein Vista habe :)

Die beiden Vorschläge werd ich mir aber mal durch den Kopf gehen lassen, das hört sich recht gut an :)

[nicodex]

Zitat:

Zitat von devidespe

Wie verhält sich das Programm unter Vista, wenn es ohne Admin-Rechte gestartet wird ?

Es startet und zeigt die Informationen an.


BiosHelp wurde dafür geschrieben, um möglichst ohne administrative Rechte an die Informationen zu gelangen.
Es gibt nur einen Fall in dem administrative Rechte benötigt werden: Ein 64-Bit Windows ohne GetSystemFirmwareTable('FIRM'/'RSMB'). In diesem speziellen Fall bräuchte man Zugriff auf das Objekt \Device\PhysicalMemory (die so ausgelesenen Informationen sind nicht 'verlässlich' genug, weshalb man darauf auch verzichten kann...).


@Ghostwalker: Es wäre nett, wenn du den Hersteller der Speichermodule anzeigen könntest (siehe Unit im Anhang).

[Ghostwalker]

Kein Problem und Thx :)

[Larsi]

Cooles Ding, du kannst das ganze ja auch im blauen Design des Bioses sowie gleiche tasten machen das wäre lustig :)

[Muetze1]

Also auf meinem Hauptrechner funktioniert es nicht (Einsprungspunkte stimmen nicht, o.ä.), aber auf meinem Laptop klappt es wunderbar. Die Akkuinformationen sind recht interessant (und korrekt) und auch die Seriennummer/exakte Modellnummer, etc. klappt - bin begeistert.

[nicodex]

Zitat:

Zitat von Muetze1

Also auf meinem Hauptrechner funktioniert es nicht (Einsprungspunkte stimmen nicht, o.ä.)

Guten Morgen.

Welches Betriebssystem?
Wird nach 'Dump / Detect from current Computer' unter 'SMBios Informations / View EntryPoint of SMBIOS' etwas angezeigt? ('Table Adress', ist am interessantesten)

[Muetze1]

OS: So, Windows XP 2002 SP2 und aktuelle Patches
Meldung im Detail: Error dumping BIOS (Size of Entry Point is incorrect)

Ich wollte dann ein Dump machen und habe als Dateiname nur "bios" angegeben, da der aktuelle Filter ja schon ein *.bin anbietet. Dabei dann erstmal Fehlermeldung, dass er kein "pfad\bios.*.bin" anlegen kann. Ok, dann halt mit Endung...

Und nochmal zur Klarheit: Bei "Dump / Detect from current Computer" erscheint die Meldung und dann nichts weiter - das Programm ist unverändert, also der Startzustand. Die anderen Menüpunkte bleiben ausgegraut und somit kann ich nicht unter dem o.g. Menüpunkt nachschauen.

Korrektur: Der Anhang ist ja mein VGA BIOS, der UMB Bereich und das System BIOS. Du dumpst ja anscheinend alles ab 0xc0000 bis 0xfffff.

[Ghostwalker]

Das ist richtig, was die Adressen betrifft. Es gibt ja keine feste Stelle an der das SMBIOS innerhalb vom Rombios startet :)

Das Problem in deinem Fall ist aber, das die eingetragene Größe des Startheaders vom SMBIOS (Entrypoint) nicht mit der Größe übereinstimmt, die im Standard definiert ist.

[Muetze1]

Zitat:

Zitat von Ghostwalker

Das ist richtig, was die Adressen betrifft. Es gibt ja keine feste Stelle an der das SMBIOS innerhalb vom Rombios startet :)

Nun ja, du kannst ja ROMs finden, die haben schliesslich alle einen Header mit Kennung und Größenangabe. Und der UMB Bereich hat bestimmt keinen solchen.

Zitat:

Zitat von Ghostwalker

Das Problem in deinem Fall ist aber, das die eingetragene Größe des Startheaders vom SMBIOS (Entrypoint) nicht mit der Größe übereinstimmt, die im Standard definiert ist.

Und ich dachte immer, mehr wäre besser ^^ Mehr Info's halt.

[Ghostwalker]

Nicht wenn sie im Standard nicht definiert sind.*G*

Ich hatte vorgestern selbst erst so einen Rechner vor mir. Dummerweise stimmen die Adresse für die Table und sonstige Daten hinten und vorne nicht.

[nicodex]

Zitat:

Zitat von Ghostwalker

Nicht wenn sie im Standard nicht definiert sind.

In den verschiedenen Revisionen der Standards sind nur 'empfohlene' (Mindest)Größen vorgegeben.
Revision 2.1 enthielt einen Fehler bei der Größenangabe der SMBIOS Entry Point Structure (1E statt 1F, da es sich beim letzten Byte ohnehin nur um die BCD-Revision handelt, kann man diesen 'Fehler' ignorieren).

ps@Muetze1: Deine EPS ist ein Byte größer als im Standard definiert (was kein Problem darstellt). Danke für die Informationen.

[Ghostwalker]

@Nico

Welche Daten erwartet deine JEDEC-Funktion ? Ich kann mir nicht ganz Vorstellen, das Type17->Manufacturer das richtige wäre (insbesondere wenn ich mir den Inhalt angug) :)

[nicodex]

Zitat:

Zitat von Ghostwalker

Welche Daten erwartet deine JEDEC-Funktion ?

Die Herstellerinformation im SMBIOS-Block ist ein AnsiString. Also JedecManufacturerFromString(Type17.Manufacturer). Diese Konvertiert den Hexadezimalstring in eine Bytesequenz und ruft intern JedecManufacturerFromBinary() auf.

Beispiele:
"7F98000000000000" -> "Kingston"
"7F7F7F0B00000000" -> "Nanya Technology"

[DevidEspenschied]

Wobei man hier noch erwähnen sollte, dass $7F quasi als Platzhalter fungiert und der String von Links abgearbeitet werden muss. Der erste 2-stellige hexadezimale Wert, welcher nicht $7F ist, definiert den Speicherhersteller.

Die Position, an der dieser zweistellige Hex-Wert steht, definiert wiederum, welche Bank für die Analyse heranzuziehen ist. Um die beiden Beispiele zu verwenden:

"7F98000000000000" -> "Kingston"

$98 an 2ter Stelle, also Bank 2, steht für Kingston

"7F7F7F0B00000000" -> "Nanya Technology"

$0B an 4ter Stelle, also Bank 4, steht für Nanya Technology

Die Funktionen in der Unit nehmen Dir die Arbeit weitestgehend ab.

[nicodex]

Zitat:

Zitat von devidespe

Die Funktionen in der Unit nehmen Dir die Arbeit weitestgehend ab.

Unter anderem die Prüfung des Paritätsbits :)

[DevidEspenschied]

Bekommt man die Unit so einfach von der Jedec ?

Das Paritätsbit hatte ich eigentlich nie groß beachtet, und kann im ersten Ansatz auch keinen Vorteil für die Erkennung des Herstellers erkennen. Werde mich damit mal beschäftigen...

[RWarnecke]

Hallo Ghostwalker,

nettes Tool. Ich habe es jetzt mal auf einem alten IBM ThinkPad T23 ausprobiert. Es zeigt soweit alles richtig an. Mach weiter so. :thumb:

[nicodex]

Zitat:

Zitat von devidespe

Bekommt man die Unit so einfach von der Jedec ?

Die Unit habe ich geschrieben.
Man kann sich auf der JEDEC-Seite kostenlos registrieren und die Spezifikation als PDF herunterladen.

Zitat:

Zitat von devidespe

Das Paritätsbit hatte ich eigentlich nie groß beachtet, und kann im ersten Ansatz auch keinen Vorteil für die Erkennung des Herstellers erkennen.

Das Paritätsbit halbiert zwar Anzahl der möglichen Codes pro Block. Im Gegenzug ist dannn aber die Wahrscheinlichkeit 2:1, dass kein Datenfehler aufgetreten ist und es sich um einen gültigen Datensatz handelt.

[Ghostwalker]

hmm...irgendwie scheint sich keiner an den Standard zu halten.*G*

Bei allen mir vorliegenden Dumps, kommt garnix raus (AMI,PHONIX,AWARD,OEM's;2003-2007). Entweder ist der String gleich leer,
oder es stehen so sinnvolle Inhalte wie "Manufacturer 0" drin. Im einzigen Fall, in dem im String, annähernd, etwas sinvolles
drinn steht ("Micron Technologies"), bringt deine Routine auch nix, da der Hersteller ja schon im Klartext drinn steht.

:wall:

[nicodex]

Dann mach’s halt so, dass du den Wert ausgibst, und - falls die JEDEC-Funktion einen String zurück gibt - es in Klammern dahinter schreibst.

[Ghostwalker]

Erste Screenshot der neuen Version. Ich werde versuchen eine erste Alpha heute noch hochzuladen, die die meisten neuen Featueres
beinhaltet.

[Ghostwalker]

So...Alpha 1 ist nun zum downlaod bereit.

Was nocht fehlt:

Conformance-Check für 2.6-Specification
und mehr Sprachen (sprich Übersetzungen).

[welle]

Hallo Ghostwalker :)

Hinter System Slots -> System Slot -> Slot Designation kommen bei mir nur "komische" Zeichen, ansonsten ein gutes Programm. :)

[Ghostwalker]

Diese komischen Zeichen stehen in deinem Bios drinn :zwinker:

[Muetze1]

Zitat:

Zitat von nicodex

ps@Muetze1: Deine EPS ist ein Byte größer als im Standard definiert (was kein Problem darstellt). Danke für die Informationen.

Hmm, aber die aktuelle Version meldet halt immernoch den Fehler (korrekter Weise), aber es stellt wohl doch ein Problem dar, denn ich bekomme keine Informationen. Dies eine Byte mehr sollte doch wohl nicht die gesamte Dekodierung be/verhindern?

Auch finde ich das neue Menü sehr unleserlich, da gefiel mir das graue Menu der ersten Version deutlich besser (siehe Anhang).

[Ghostwalker]

@Muetze1

Doch, schließlich weiß ich nicht, wo in der Struktur das Byte mehr liegt. Ist es z.B. vor der Startadresse für die Tabelleeinträge, greif ich für die Dekodierung auf falsche Daten zu (im günstigsten Fall !).

Ich habe hier testhalber mal den Fehler übergangen. Das Ergebnis war ein einziges Chaos. :)

bzgl. Menü

Öhm....das ist eine ganz normale Toolbar2000 die ich hier verwende. Wundert mich etwas das das bei dir so komisch aussieht. Hast du mit anderen Programmen, die die Toolbar2000 verwenden, das gleiche Problem ?

[RWarnecke]

Zitat:

Zitat von Ghostwalker

bzgl. Menü

Öhm....das ist eine ganz normale Toolbar2000 die ich hier verwende. Wundert mich etwas das das bei dir so komisch aussieht. Hast du mit anderen Programmen, die die Toolbar2000 verwenden, das gleiche Problem ?

Bei mir unter Vista x64 SP1 sieht es genau so aus.

[Ghostwalker]

ok..dann ersetz ich die TB2000 wieder durch ein normales MainMenu.

[Ghostwalker]

So...erste Beta steht online :)

[EarthQuaker]

Hallo, bei mir läuft auch alles soweit ganz gut.. würde sagen gut gelungen... aber habe da mal eine frage... und zwar gibts davon source? bzw. könntest mir helfen? weil ich habe mal was ähnliches angefangen aber wensch speicher auslesen will gehts nicht... bzw. habsch keine ahnung wie ich z.b RAM Typ und geschwindigkeit auslese... etc.

[RavenIV]

Cooles Programm, weiter so.

Allerdings einige Anregungen / Kritik:
- ich kenne es so, dass Beta-Versionen eine Versionsnummer kleiner 1 haben, z.B. 0.7Beta1
- zur Baumstruktur links: hat man einen Untereintrag ausgewählt und schliesst den Zweig, sollte der Zweig markiert werden. Sonst weiss man nach Schliessen des Zweiges nicht mehr, wo man eigentlich ist.
- Im Menu soll es nicht "About" heissen, sondern "Help" und dann einen Unterpunkt "About", der das About-Fenster öffnet
- Im About-Fenster fehlt eine email-Adresse und vielleicht eine webseite
- Programm nicht Desktop-Center starten lassen, sondern ScreenCenter. Sonst klebt es bei zwei Bildschirmen so hässlich zwischen den beiden Bildschirmen
- Fensterposition und -grösse bei beenden merken und bei starten wieder herstellen
- Konform-Fenster: deutsche Übersetzung nicht komplett "SMBIOS entspricht nicht der", da fehlt doch was. Ist das Label zu kurz?
- Konform-Fenster: Fenster kann bis auf Titelleiste verkleinert werden. Minimal-Grösse festlegen
- Konform-Fenster: der Schliessen-Button geht nicht mit, wenn man das Fenster vergrössert

[Horst0815]

Zitat:

Zitat von nicodex (Beitrag 782179)

Zitat:

Zitat von devidespe

Wie verhält sich das Programm unter Vista, wenn es ohne Admin-Rechte gestartet wird ?

Es startet und zeigt die Informationen an.


BiosHelp wurde dafür geschrieben, um möglichst ohne administrative Rechte an die Informationen zu gelangen.
Es gibt nur einen Fall in dem administrative Rechte benötigt werden: Ein 64-Bit Windows ohne GetSystemFirmwareTable('FIRM'/'RSMB'). In diesem speziellen Fall bräuchte man Zugriff auf das Objekt \Device\PhysicalMemory (die so ausgelesenen Informationen sind nicht 'verlässlich' genug, weshalb man darauf auch verzichten kann...).


@Ghostwalker: Es wäre nett, wenn du den Hersteller der Speichermodule anzeigen könntest (siehe Unit im Anhang).

Falls es jemand braucht, hab die Unit mal für ein eigenes Projekt aktualisiert