Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

IT-Systeme Hardware und Betriebssysteme – Treiber und Geräteprobleme eingrenzen

QR-Code

IT-Systeme Hardware und Betriebssysteme – Treiber und Geräteprobleme eingrenzen

Einleitung

Warum funktioniert ein Gerät plötzlich nicht mehr? Liegt es an der Hardware, am Anschluss, am Betriebssystem oder am Treiber?

In diesem aiMOOC lernst Du, Geräteprobleme systematisch einzugrenzen, Kompatibilität zu überprüfen und Diagnosen nachvollziehbar zu dokumentieren.

Zielgruppe: Ausbildung im IT-Bereich, insbesondere Fachinformatikerinnen und Fachinformatiker sowie IT-Systemelektronikerinnen und IT-Systemelektroniker.

Dauer: ca. 70–90 Minuten inklusive Übungen.

Lernziele:

Gerätetreiber und Hardware unterscheiden und ihr Zusammenspiel erklären.
Hardwarekompatibilität anhand von Gerätekennungen, Betriebssystem, Architektur und Treiberfreigaben beurteilen.
Fehlerdiagnose mit kontrollierten Vergleichstests durchführen.
Diagnoseergebnisse begründet dokumentieren.
IT-Sicherheit und Datenschutz bei Tests berücksichtigen.

Sicherheitsregel: Alle praktischen Beispiele verwenden fiktive Daten und laufen offline. Arbeite ausschließlich in einer eigenen lokalen oder ausdrücklich autorisierten Testumgebung. Keine Eingriffe in Produktivsysteme, keine fremden Netze, keine echten Kunden- oder Zugangsdaten und keine ungefragte Datenübertragung.

Leitfrage: An welcher Stelle zwischen Software, Treiber und Hardware entsteht der Fehler?

Lernpfad: Sechs kurze Einheiten

Einheit	Inhalt	Zeit
1	Hardware und Treiber verstehen	8 Min.
2	Kompatibilität prüfen	10 Min.
3	Fehler systematisch eingrenzen	10 Min.
4	Windows und Linux vergleichen	12 Min.
5	Ausbildungsfall und Offline-Simulator	20 Min.
6	Diagnose dokumentieren und übertragen	10 Min.

Einheit 1: Hardware, Betriebssystem und Treiber

Ein Gerätetreiber vermittelt zwischen Betriebssystem und Hardware. Er ermöglicht, dass das Betriebssystem gerätespezifische Funktionen nutzen kann.

Anwendung
    |
Betriebssystem
    |
Gerätetreiber
    |
Geräteschnittstelle
    |
Hardware

Merke: Ein erkanntes Gerät ist nicht automatisch ein funktionierendes Gerät.

Mini-Aufgabe: Erkläre, weshalb ein USB-Gerät im Betriebssystem erscheinen kann, obwohl seine eigentliche Funktion nicht startet.

Begründetes Feedback: Die physische Erkennung und die Initialisierung durch den passenden Treiber sind unterschiedliche Schritte. Eine erfolgreiche Erkennung beweist daher noch keine vollständige Funktion.

Einheit 2: Kompatibilität prüfen

Ein Treiber muss zur Hardware und zur vorgesehenen Systemumgebung passen.

Prüfe besonders:

Gerätekennung und Gerätemodell beziehungsweise Revision.
Betriebssystem und unterstützte Version.
Prozessorarchitektur wie x64 oder ARM64.
Treiberversion und Herstellerfreigabe.
Digitale Signatur und vertrauenswürdige Bezugsquelle.

Wichtig: Der Steckertyp USB-C allein garantiert weder eine bestimmte Übertragungsgeschwindigkeit noch sämtliche USB-C-Zusatzfunktionen.

Bei Problemen mit einem USB-Hub prüfst Du auch Verbindung, Stromversorgung und einen direkten Anschluss als kontrollierten Vergleich.

Mini-Aufgabe: Ein Gerät funktioniert direkt am Testrechner, aber nicht über einen Hub. Welche zwei Ursachen würdest Du zuerst untersuchen?

Begründetes Feedback: Der Direktanschluss zeigt, dass das Gerät unter diesen Bedingungen arbeitet. Deshalb sind der Hub, seine Stromversorgung und die zusätzliche Kabelstrecke zunächst plausiblere Prüfpunkte als eine allgemeine Treiberinkompatibilität.

Einheit 3: Geräteprobleme systematisch eingrenzen

Diagnoseregel: Immer nur eine Einflussgröße verändern.

Symptom erfassen
       |
Gerät sichtbar?
   |          |
  Nein        Ja
   |          |
Kabel,      Status und
Port und    Problemcode
Strom       prüfen
   |          |
Vergleichstest mit
bekannt funktionierender
Komponente
       |
Treiberkompatibilität
und Protokolle prüfen
       |
Ergebnis dokumentieren

Typische Windows-Problemcodes:

Code	Bedeutung	Diagnostische Einordnung
10	Gerät konnte nicht starten	Treiber, Initialisierung und Hardware prüfen
28	Treiberinstallation fehlgeschlagen	Passendes Treiberpaket überprüfen
43	Gerät meldete nach dem Start ein Problem	Weitere Protokolle und Vergleichstests erforderlich
52	Treibersignatur kann nicht überprüft werden	Signatur und vertrauenswürdige Quelle prüfen

Achtung: Ein Problemcode benennt einen Zustand, beweist aber nicht allein die Ursache.

Video: Microsoft – Treiber aktualisieren, neu installieren und zurücksetzen

Videoauftrag: Notiere, worin sich Aktualisieren, Neuinstallation und Zurücksetzen auf eine frühere Treiberversion unterscheiden. Führe die gezeigten Änderungen nicht an einem Produktivsystem aus.

Einheit 4: Diagnosewerkzeuge unter Windows und Linux

Windows

Der Geräte-Manager zeigt Geräte, Treiberinformationen, Hardwarekennungen und Fehlerzustände.

Für eine ausdrücklich autorisierte Windows-Testmaschine sind folgende lesende Diagnosebefehle relevant:

pnputil /enum-devices /problem
pnputil /enum-drivers

Die verfügbaren Optionen hängen von der Windows-Version ab. Das Installationsprotokoll %SystemRoot%\inf\SetupAPI.dev.log kann bei der Analyse von Treiberinstallationen helfen.

Keine Installation, Deaktivierung oder Treiberlöschung ohne Freigabe und Rückfallplan.

Linux

Linux nutzt unter anderem Kernelmodule und das Treibermodell des Kernels zur Geräteanbindung.

Lesende Diagnosebefehle für eine lokale Linux-Laborumgebung:

lsusb
lspci -nnk
lsmod
journalctl -k -b

Werkzeug	Zweck
lsusb	USB-Geräte auflisten
lspci -nnk	PCI-Geräte und Kernel-Treiberinformationen betrachten
lsmod	Geladene Kernelmodule anzeigen
journalctl -k -b	Kernelmeldungen des aktuellen Starts betrachten

Die Werkzeuge können je nach Distribution fehlen; einzelne Protokolle benötigen zusätzliche Leseberechtigungen.

Video: LearnLinuxTV – Hardware im Linux-Terminal untersuchen

Transferfrage: Welche Beobachtungen sind bei Windows und Linux vergleichbar, obwohl unterschiedliche Diagnosewerkzeuge verwendet werden?

Feedback: In beiden Fällen geht es um Hardwareerkennung, Treiberzuordnung, Fehlermeldungen und reproduzierbare Funktionstests. Die Werkzeuge unterscheiden sich, die diagnostische Logik ist ähnlich.

Ausbildungsfall: Der Scanner funktioniert nicht

Fiktiver Ausbildungsbetrieb: IT-Lernwerkstatt Nord

Ticket LAB-042: Der USB-Scanner „SimScan-42“, Revision A, funktionierte im Windows-11-x64-Testsystem. Nach einem Treiberwechsel startet er nicht mehr.

Beobachtungen:

Das Gerät ist weiterhin sichtbar.
Der simulierte Geräte-Manager zeigt Code 10.
Das neue Treiberpaket 3.0 ist laut fiktiver Freigabeliste nur für Revision B vorgesehen.
Das vorherige Paket 2.2 unterstützt Revision A.
Alle Angaben sind ausschließlich erfundene Ausbildungsdaten.

Kompatibilitätsmatrix

Gerät	Treiber	Freigabe	Simuliertes Ergebnis
SimScan-42 Rev. A	2.2	Rev. A, Windows 11 x64	Funktioniert
SimScan-42 Rev. A	3.0	Rev. B, Windows 11 x64	Startproblem
SimCam-8	1.1	Windows 11 x64	Direktanschluss funktioniert

Wichtig: Diese Matrix beschreibt keine realen Produkte oder tatsächlichen Herstellerfreigaben.

Visualisierte Testdaten

Erfolgreiche Scans aus acht Versuchen

Vor Wechsel, direkt     ████████  8/8
Nach Wechsel, direkt    ........  0/8
Nach Wechsel, am Hub    ........  0/8
Simulierter Rollback    ████████  8/8

Legende:
█  erfolgreicher Scan
.  nicht erfolgreicher Scan

Arbeitsauftrag: Formuliere eine Hypothese, benenne zwei stützende Beobachtungen und erkläre, weshalb ein Rückwechseltest aussagekräftiger ist als eine bloße Vermutung.

Gestufte Hilfen

Hilfe 1 – Beobachten

Was bleibt unverändert? Was hat sich unmittelbar vor dem Problem verändert?

Hilfe 2 – Vergleichen

Vergleiche die Geräterevision mit der Freigabe beider Treiberpakete.

Hilfe 3 – Begründen

Wenn derselbe Scanner unter gleichen Testbedingungen mit Paket 2.2 funktioniert, mit Paket 3.0 aber nicht, spricht dies für ein Problem im Zusammenhang mit dem Paketwechsel. Weitere Fehlerquellen sind trotzdem zu berücksichtigen.

Begründete Musterlösung

Musterlösung anzeigen

Hypothese: Das neue Treiberpaket ist mit der vorhandenen Geräterevision nicht kompatibel.

Belege: Das Gerät wird erkannt, startet aber nach dem Paketwechsel nicht. Die fiktive Freigabeliste schließt Revision A für Paket 3.0 aus.

Kontrolltest: In einer isolierten Testumgebung wird das zuvor funktionierende Paket erneut simuliert beziehungsweise kontrolliert getestet.

Ergebnis: Die Rückkehr zur alten, freigegebenen Version stellt im simulierten Datensatz die Funktion wieder her. Das stützt die Hypothese, ersetzt aber bei einem realen Vorfall keine vollständige Prüfung.

Dokumentation: Fehlerbild, System, Geräterevision, Paketversion, Zeitpunkt, Testbedingungen, Messwerte und Ergebnis festhalten.

Offline-Testlabor: Interaktiver Python-Diagnosesimulator

Ziel: Teste drei fiktive Fehlerfälle, ohne auf echte Hardware, Netzwerke oder Betriebssystemkonfigurationen zuzugreifen.

Voraussetzung: Lokal installiertes Python 3. Keine Zusatzpakete.

Start: Speichere den folgenden Code als diagnose_demo.py. Führe ihn in einer lokalen Python-Umgebung aus.

python diagnose_demo.py --test
python diagnose_demo.py

Ausführbarer Python-Code:

import sys

# Ausschliesslich erfundene Labordaten.
# Kein Netzwerk, kein Dateizugriff, keine Systembefehle.
FAELLE = [
    {
        "name": "SimScan-42",
        "id": "SIM-USB-042",
        "os": "Windows 11 x64",
        "revision": "A",
        "freigabe": "B",
        "treiber": "3.0",
        "code": 10,
        "erkannt": True,
        "direkt": 0,
        "hub": 0,
    },
    {
        "name": "SimCam-8",
        "id": "SIM-USB-008",
        "os": "Windows 11 x64",
        "revision": "A",
        "freigabe": "A",
        "treiber": "1.1",
        "code": None,
        "erkannt": True,
        "direkt": 8,
        "hub": 0,
    },
    {
        "name": "SimLink-5",
        "id": "SIM-USB-005",
        "os": "Windows 11 x64",
        "revision": "A",
        "freigabe": "A",
        "treiber": "1.1",
        "code": None,
        "erkannt": False,
        "direkt": 0,
        "hub": 0,
    },
]

BEGRUENDUNGEN = [
    "Code 10 und fehlende Freigabe fuer Rev. A "
    "stuetzen eine Treiberhypothese.",
    "Direkt 8/8, am Hub 0/8: Hub, Kabel "
    "oder Versorgung gezielt vergleichen.",
    "Das Geraet wird nicht erkannt: zuerst "
    "Erkennung, Anschluss und Strom pruefen. "
    "Die Ursache ist noch nicht bewiesen.",
]


def diagnose(fall):
    if not fall["erkannt"]:
        return "erkennung"
    if fall["direkt"] > fall["hub"]:
        return "hub"
    if (fall["code"] == 10
            and fall["revision"] != fall["freigabe"]):
        return "treiber"
    return "offen"


def balken(wert):
    return "#" * wert + "." * (8 - wert)


def zeige(fall):
    print("\nGeraet:", fall["name"])
    print("Kennung:", fall["id"])
    print("System:", fall["os"])
    print("Revision:", fall["revision"])
    print("Treiber:", fall["treiber"])
    print("Freigabe fuer Revision:", fall["freigabe"])
    print("Erkannt:", "ja" if fall["erkannt"] else "nein")
    print("Problemcode:", fall["code"])
    print("Direkt:", balken(fall["direkt"]),
          str(fall["direkt"]) + "/8")
    print("Hub:   ", balken(fall["hub"]),
          str(fall["hub"]) + "/8")


def selbsttest():
    ergebnisse = [diagnose(f) for f in FAELLE]
    assert ergebnisse == [
        "treiber", "hub", "erkennung"
    ]
    assert balken(8) == "########"
    assert balken(0) == "........"
    print("Alle 3 Offline-Selbsttests bestanden.")


def hauptprogramm():
    print("OFFLINE-LABOR: Nur fiktive Daten!")
    while True:
        wahl = input(
            "\nFall 1, 2, 3 oder q zum Beenden: "
        ).strip().lower()

        if wahl == "q":
            break
        if wahl not in ("1", "2", "3"):
            print("Bitte 1, 2, 3 oder q eingeben.")
            continue

        nummer = int(wahl) - 1
        fall = FAELLE[nummer].copy()
        zeige(fall)

        antwort = input(
            "Erste Pruefebene? "
            "treiber/hub/erkennung: "
        ).strip().lower()

        if antwort == diagnose(fall):
            print("Passende erste Pruefebene.")
        else:
            print("Noch nicht gut genug belegt.")

        print("Begruendung:", BEGRUENDUNGEN[nummer])

        if nummer == 0:
            frage = input(
                "Virtuellen Rollback testen? j/n: "
            ).strip().lower()
            if frage == "j":
                neu = fall.copy()
                neu.update({
                    "treiber": "2.2",
                    "freigabe": "A",
                    "code": None,
                    "direkt": 8,
                    "hub": 8,
                })
                print("Nur simulierte Aenderung:")
                zeige(neu)


if __name__ == "__main__":
    if len(sys.argv) > 1 and sys.argv[1] == "--test":
        selbsttest()
    else:
        hauptprogramm()

Was Du erprobst:

Fall 1: Treiberkompatibilität prüfen und einen virtuellen Rollback durchführen.
Fall 2: Direktanschluss und USB-Hub vergleichen.
Fall 3: Fehlende Geräteerkennung von einem nachgewiesenen Treiberproblem unterscheiden.

Auswertung: Begründe zu jedem Fall, warum Deine erste Prüfebene sinnvoll ist und welche Beobachtung Du zusätzlich benötigst.

Sicherheitsnachweis: Das Programm arbeitet ausschließlich mit fest eingebauten fiktiven Datensätzen, schreibt keine Dateien, installiert keine Treiber, verändert kein System und führt keine Netzwerkzugriffe aus.

Zweites lokales Codebeispiel: PowerShell

Dieser Code erstellt nur fiktive Diagnoseobjekte und zeigt sie an. Er liest keine echten Geräteinformationen.

$daten = @(
    [pscustomobject]@{
        Geraet = "SimScan-42"
        Code = 10
        Pruefung = "Treiberkompatibilitaet"
    }
    [pscustomobject]@{
        Geraet = "SimCam-8"
        Code = 0
        Pruefung = "USB-Hub"
    }
)

$daten | Format-Table -AutoSize

Mini-Auftrag: Ergänze lokal einen dritten fiktiven Datensatz. Erkläre, warum der Problemcode allein für eine Diagnose nicht ausreicht.

Einheit 6: Diagnose nachvollziehbar dokumentieren

Ein professionelles Diagnoseticket trennt Beobachtung, Hypothese, Test und Schlussfolgerung.

Feld	Beispiel LAB-042
Symptom	Scanner startet nicht
Umgebung	Fiktives Windows-11-x64-Labor
Gerätekennung	SIM-USB-042, Revision A
Beobachtung	Gerät erkannt, Code 10
Änderung	Treiber 2.2 auf 3.0
Hypothese	Fehlende Freigabe für Revision A
Vergleichstest	Virtueller Rückwechsel auf 2.2
Ergebnis	Im Simulator wieder 8 von 8 erfolgreichen Scans
Restunsicherheit	Reales Gerät nicht getestet
Empfehlung	Nur nach Freigabe im Testsystem verifizieren

Qualitätskriterium: Eine andere Fachkraft muss Deinen Test nachvollziehen können, ohne dass Du ihr die Lösung mündlich erklärst.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Welche Aufgabe hat ein Gerätetreiber? (Er vermittelt zwischen Betriebssystem und Hardware) (!Er ersetzt die physische Hardware) (!Er ist ausschließlich für die Stromversorgung zuständig) (!Er erstellt automatisch Datensicherungen)

Was sollte am Anfang einer nachvollziehbaren Fehlerdiagnose stehen? (Die genaue Beschreibung des Symptoms) (!Das sofortige Löschen aller Treiber) (!Die Neuinstallation des Betriebssystems) (!Der Austausch sämtlicher Komponenten)

Was bedeutet Windows-Problemcode 28? (Die Treiberinstallation ist fehlgeschlagen) (!Das Gerät ist sicher mechanisch beschädigt) (!Der Bildschirm ist ausgeschaltet) (!Das Netzwerkkabel wurde entfernt)

Was bezeichnet Windows-Problemcode 10? (Das Gerät konnte nicht starten) (!Das Gerät ist vollständig funktionsfähig) (!Der Arbeitsspeicher ist immer defekt) (!Das Betriebssystem besitzt keine Benutzerkonten)

Welche Aussage zu USB-C ist korrekt? (Die Steckerform allein garantiert keine bestimmte Geschwindigkeit) (!Jeder USB-C-Anschluss unterstützt jede Videoausgabe) (!Alle USB-C-Kabel besitzen identische Eigenschaften) (!USB-C bezeichnet ausschließlich einen Netzwerktreiber)

Was gehört zur Prüfung der Treiberkompatibilität? (Geräterevision und Treiberfreigabe vergleichen) (!Nur die Farbe des Kabels vergleichen) (!Ausschließlich den Gerätenamen betrachten) (!Immer den neuesten Treiber ohne Prüfung installieren)

Was zeigt ein erkanntes aber nicht startendes Gerät? (Erkennung und vollständige Funktion sind verschieden) (!Das Gerät ist sicher vollständig in Ordnung) (!Eine Treiberprüfung ist grundsätzlich sinnlos) (!Ein Defekt des Prozessors ist bewiesen)

Ein USB-Gerät funktioniert direkt aber nicht am Hub. Welcher Verdacht liegt nahe? (Ein Problem am Hub oder seiner Verbindung) (!Ein grundsätzlich ungeeignetes Betriebssystem ist bewiesen) (!Der Prozessor ist immer überlastet) (!Das Dateisystem muss formatiert werden)

Ein USB-Gerät wird auch am direkten Testanschluss nicht erkannt. Was ist ein sinnvoller erster Schritt? (Anschluss und physische Erkennung kontrollieren) (!Ungeprüfte Treiber aus dem Internet installieren) (!Alle Geräte im System deaktivieren) (!Ohne Diagnose einen Hardwaredefekt behaupten)

Welche Handlung entspricht professioneller IT-Diagnose? (Tests dokumentieren und nur in freigegebener Umgebung durchführen) (!Echte Kundendaten an unbekannte Dienste senden) (!Produktivsysteme ohne Freigabe verändern) (!Fehlermeldungen ohne Prüfung ignorieren)

Feedback zum Quiz: Entscheidend ist nicht nur die richtige Antwort. Begründe Deine Auswahl mit einer Beobachtung oder einem technischen Zusammenhang. Ein Fehlercode ist ein Hinweis, keine vollständige Ursachenanalyse.

Memory

Gerätetreiber	Schnittstelle zwischen Betriebssystem und Hardware
Gerätekennung	Identifikationsmerkmal eines erkannten Geräts
Direktanschluss	Verbindung ohne zwischengeschalteten Hub
Treiberrollback	Rückkehr zur vorherigen Treiberversion
Kernelmodul	Ladbare Komponente des Betriebssystemkerns
Kompatibilitätsmatrix	Übersicht unterstützter Kombinationen
Diagnoseprotokoll	Dokumentation von Beobachtungen und Tests

Drag and Drop

Ordne die richtigen Begriffe zu.	Thema
Symptomerfassung	Beschreibung des beobachteten Fehlers
Geräteerkennung	Feststellen ob das System die Hardware sieht
Kompatibilitätsprüfung	Vergleich von Geräteversion und Treiberfreigabe
Vergleichstest	Untersuchung unter kontrolliert geänderten Bedingungen
Rollback	Rückkehr zu einer zuvor verwendeten Treiberversion
Dokumentation	Festhalten von Belegen und Ergebnissen

Kreuzworträtsel

Treiber	Welche Software vermittelt zwischen Betriebssystem und einem speziellen Gerät?
Firmware	Wie heißt die hardwarenahe Software eines Geräts?
Steckplatz	Wie nennt man die Aufnahme einer Erweiterungskarte auf der Hauptplatine?
Kabel	Was stellt häufig die physische Verbindung zu einem externen Gerät her?
Signatur	Wie heißt die kryptografische Kennzeichnung zur Überprüfung eines Softwarepakets?
Protokoll	Wie heißt eine nachvollziehbare Aufzeichnung von Ereignissen?

LearningApps

Lückentext

Ein

ermöglicht dem Betriebssystem die Kommunikation mit spezifischer Hardware.

Die automatische Erkennung und Einbindung geeigneter Geräte wird häufig durch

unterstützt.

Eine erkannte Hardware muss nicht zwangsläufig vollständig

.

Bei Windows zeigt der Geräte-Manager Informationen über installierte

.

Für die Kompatibilität ist die unterstützte Betriebssystemarchitektur wie

relevant.

Ein fehlerhaftes USB-Gerät sollte zunächst an einem bekannten funktionierenden

getestet werden.

Die Rückkehr zu einer vorherigen Treiberversion heißt

.

Unter Linux kann das Werkzeug

USB-Geräte auflisten.

Eine begründete Vermutung über die Fehlerursache heißt

.

Alle Prüfschritte und Ergebnisse gehören in ein nachvollziehbares

.

Offene Aufgaben

Leicht – Basisaufgaben

Hardware: Zeichne eine einfache Darstellung der Verbindung zwischen Betriebssystem, Treiber und Gerät.
Gerätetreiber: Erstelle drei Lernkarten zu den Begriffen Treiber, Gerätekennung und Problemcode.
USB: Vergleiche zwei der eingebundenen Anschlussbilder und beschreibe erkennbare Unterschiede.
Fehlerdiagnose: Formuliere fünf sachliche Fragen, mit denen Du ein Geräteproblem systematisch erfassen kannst.

Begründetes Feedback – Basis: Gute Lösungen trennen Begriffe sauber und beschreiben Beobachtungen, ohne daraus unbelegte Ursachen abzuleiten.

Standard – Anwendungsaufgaben

Kompatibilität: Werte die fiktive Freigabematrix des SimScan-42 aus und begründe die Auswahl einer geeigneten Treiberversion.
Python: Starte den Offline-Simulator, bearbeite alle drei Fälle und vergleiche die ausgegebenen Begründungen.
USB-Hub: Entwickle zwei kontrollierte Tests, um eine Verbindungsstörung von einem Treiberproblem abzugrenzen.
IT-Dokumentation: Schreibe ein kurzes Diagnoseticket zum Fall LAB-042 mit Beobachtungen, Hypothese, Test und Ergebnis.

Begründetes Feedback – Anwendung: Überzeugend ist eine Lösung dann, wenn sie aus konkreten Messwerten eine überprüfbare Hypothese ableitet und alternative Ursachen berücksichtigt.

Schwer – Transferaufgaben

Fehleranalyse: Entwickle einen Entscheidungsbaum für drei Fehlerbilder: nicht erkanntes Gerät, nicht startendes Gerät und zeitweise ausfallendes Gerät.
Softwaretest: Erweitere den lokalen Python-Simulator um einen vierten fiktiven Fall mit begründeter automatischer Rückmeldung und mindestens einem Selbsttest.
IT-Sicherheit: Entwerfe eine Freigabe- und Rückfallstrategie für Treiberänderungen in einer isolierten Ausbildungsumgebung und erkläre die Risiken unkontrollierter Änderungen.
Projektarbeit: Produziere ein zweiminütiges Lehrvideo oder eine Präsentation, in der Du einen vollständig fiktiven Diagnosefall mit visualisierten Daten und begründeter Schlussfolgerung erklärst.

Begründetes Feedback – Transfer: Eine hochwertige Bearbeitung ist reproduzierbar, berücksichtigt Unsicherheiten und vermeidet riskante oder nicht autorisierte Eingriffe.

Lernkontrolle

Bearbeite die Aufgaben schriftlich oder in einer praktischen Prüfung mit fiktiven Daten.

Ursachenanalyse: Ein Drucker erscheint im Geräte-Manager, druckt aber nicht. Entwickle mindestens drei alternative Hypothesen und passende Unterscheidungstests.
Hardwarediagnose: Ein USB-Gerät funktioniert an einem Direktanschluss, jedoch nicht an zwei Hubs. Begründe, welche zusätzlichen Testbedingungen Du kontrollieren musst.
Treiberkompatibilität: Ein neuer Treiber verursacht nach einem Update ein Problem. Beurteile, wann ein Rollback sinnvoll sein kann und welche Belege Du vorher sichern würdest.
Betriebssystemvergleich: Entwirf einen gemeinsamen Diagnoseablauf für Windows und Linux. Ordne jeder Phase jeweils mögliche Werkzeuge oder Beobachtungen zu.
Datenanalyse: Ein Gerät funktioniert bei acht Direktversuchen achtmal, am Hub zweimal. Formuliere eine Hypothese und erläutere, weshalb acht Versuche keine allgemeingültige Zuverlässigkeitsaussage erlauben.
IT-Sicherheit: Beurteile den Vorschlag, einen unbekannten Treiber auf einem betrieblichen Rechner zu installieren und Diagnosedaten an einen externen Dienst zu senden. Entwickle eine sichere Alternative.

Bewertungsmaßstab:

Kriterium	Erwartete Leistung
Fachliche Erklärung	Hardware, Treiber und System korrekt unterscheiden
Diagnoseplanung	Sinnvolle Testreihenfolge und kontrollierte Variablen
Begründung	Aussagen mit Beobachtungen stützen
Transfer	Vorgehen auf neue Fehlerbilder übertragen
Sicherheit	Autorisierung, Datenschutz und Rückfallplan beachten

Lernnachweis

Für einen erfolgreichen Lernnachweis solltest Du folgende Leistungen vorweisen können:

Ein korrekt beschriftetes Modell zum Zusammenspiel von Hardware, Betriebssystem und Treiber.
Eine begründete Auswertung einer fiktiven Kompatibilitätsmatrix.
Die erfolgreiche Ausführung der lokalen Selbsttests des Python-Simulators.
Eine dokumentierte Bearbeitung der drei simulierten Fehlerfälle.
Ein Diagnoseprotokoll mit Symptomen, Hypothesen, Vergleichstests, Beobachtungen und begründeten Ergebnissen.
Einen selbst entwickelten Diagnoseablauf für einen neuen fiktiven Gerätefehler.
Eine nachvollziehbare Erklärung der Sicherheits- und Datenschutzgrenzen.

Bestehensziel: Du kannst anhand vorliegender Belege entscheiden, was bereits bekannt ist, welche Ursache nur vermutet wird und welcher sichere Test als Nächstes erforderlich ist.

OERs zum Thema

Wikipedia: Gerätetreiber

Weiterführende Fachquellen:

Microsoft Learn – Fehlermeldungen des Geräte-Managers: Technische Definition der Problemcodes.
Microsoft Learn – PnPUtil-Beispiele: Dokumentation der Windows-Diagnosewerkzeuge.
Microsoft Learn – SetupAPI-Protokolle: Treiberinstallationen nachvollziehen.
Microsoft Support – Gerätetreiber aktualisieren: Herstellerhinweise zu Aktualisierung und Rollback.
Linux-Kernel-Dokumentation – Driver Binding: Technische Grundlagen der Treiberzuordnung.
Linux-Handbuch – lsusb: USB-Erkennung.
Linux-Handbuch – lspci: PCI-Diagnose.
Gerätetreiber, Plug and Play, Universal Serial Bus, Linux und Betriebssystem: Weitere Grundlagen.

Mediennachweise und Nutzungsrechte

Die folgenden Dateien sind auf Wikimedia Commons nachgewiesen. Die jeweiligen Dateibeschreibungsseiten enthalten die maßgeblichen Urheber- und Lizenzinformationen.

Medium	Urheber beziehungsweise Quelle	Lizenz
Driverarch.png	Tutorial, Commons	Gemeinfrei laut Commons
USB-Steckverbinder	Matthew Wynn	CC BY-SA 4.0
USB Type-C.jpg	Flanoz	CC0 1.0
USB-Hub	FASTILY	CC BY-SA 4.0
Device Manager	Shahbaz75	CC BY-SA 4.0
PCIe-Steckplätze	Sayeen	CC BY-SA 4.0

Videos:

Microsoft – Fix driver issues in Windows: Offizielles Microsoft-Hilfevideo.
LearnLinuxTV – Hardware im Terminal untersuchen: Linux-Lernvideo.

Rechtlicher Hinweis: Die Wikimedia-Dateien dürfen im Rahmen ihrer jeweiligen Lizenzen genutzt werden; insbesondere sind die Bedingungen zur Namensnennung und Weitergabe unter gleichen Bedingungen einzuhalten. Die YouTube-Videos werden als externe Plattforminhalte eingebunden. Für sie wird keine freie Nachnutzungslizenz behauptet. Beim Abspielen externer Videos können Verbindungsdaten an die Videoplattform übermittelt werden. Die lokalen Programmbeispiele benötigen keine Internetverbindung.