SQL Server Dienst startet nicht - Fehler 1067

  • Trotz Neuinstallation startet der SQL Server Dienst nicht. "Kann den Dienst nicht starten -
    Fehlercode 1067. Der Prozess wurde unerwatet beendet.".
    Hat dazu jemand eine Idee?

    Hatte schon des SQL Server deinstalliert und neu installiert - identisches Verhalten.
    Windows 11 Pro, akuelles David.iso verwendet.

  • Mit welchem User startet der SQL-Dienst? Hast du mal testweise einen anderen ausprobiert, z. B. "Lokales System" oder einen passend berechtigten lokalen Benutzer?

    Auf welchem TCP-Port will dein SQL-Server starten? Ist dort ggf. schon ein anderes Programm aktiv? Gibt es nur diese eine SQL-Instanz auf dem PC?

  • Das Windows Ereignisprotokoll zeigt nach Neuinstallation des SQL-Servers folgenden Fehler:

    "Fehlerhafter Anwendungsname: sqlservr.exe, Version: 2017.140.1000.169, Zeitstempel: 0x599d0bc0
    Fehlerhafter Modulname: ntdll.dll, Version: 10.0.26100.8972, Zeitstempel: 0x59a29eb0
    Ausnahmecode: 0xc0000005" ...


    Hat dafür jemand eine Lösung?

  • Wurde das System mal auf defekte Systemdateien geprüft?

    terminal oder cmd als Admin starten

    sfc /Scannow

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • Hier mal das was die KI dazu sagt......

    Der Ausnahmecode 0xc0000005 steht für eine Access Violation, also einen unzulässigen Speicherzugriff des Prozesses. Dass als fehlerhaftes Modul ntdll.dll angegeben wird, bedeutet nicht zwangsläufig, dass die Windows-DLL selbst die Ursache des Problems ist. ntdll.dll ist eine zentrale Windows-Systemkomponente und kann lediglich die Stelle sein, an der der Absturz bzw. die Exception von Windows registriert wurde.

    Besonders auffällig ist der installierte Patchstand von SQL Server 2017.

    Bei Build 14.0.1000.169 handelt es sich um den ursprünglichen RTM-Stand von SQL Server 2017 aus dem Jahr 2017. Das System läuft somit auf dem ursprünglichen Basisstand der SQL-Server-Version und verfügt nicht über die zahlreichen später veröffentlichten Cumulative Updates und Fehlerkorrekturen.

    Auffällig und aus technischer Sicht deutlich kritischer ist jedoch, dass SQL Server noch mit dem ursprünglichen RTM-Build 14.0.1000.169 betrieben wird. Vor einer tiefergehenden Analyse von ntdll.dll sollte deshalb zunächst der SQL Server auf einen aktuellen Patchstand gebracht bzw. zumindest geprüft werden, ob der Absturz bereits durch ein späteres SQL-Server-Update behoben wurde.

    Nimm doch einfach mal einen SQL 2019 oder 2022

  • Ich lese gerade: Windows 11. Wie ist der Datenträger aufgeteilt?

    Troubleshoot Operating System Disk Sector Size Greater Than 4 KB - SQL Server
    This article troubleshoots SQL Server installation or startup failures related to some new storage devices and device drivers exposing a disk sector size…
    learn.microsoft.com

    Lt diesem Artikel https://learn.microsoft.com/en-us/answers/…ows-11-c0000005 soll man einen Blick in C:\Users\YourUsername\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\error.log werfen - ist dort etwas von "256 misaligned reads" protokolliert, kann obiger Bug die Ursache sein.

  • Lt diesem Artikel https://learn.microsoft.com/en-us/answers/…ows-11-c0000005 soll man einen Blick in C:\Users\YourUsername\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\error.log werfen - ist dort etwas von "256 misaligned reads" protokolliert, kann obiger Bug die Ursache sein.

    Das sieht doch schon sehr nach dem Problem aus ........

  • Der Fehler trat bei zwei Kunden mit identischer Hardware und identischen Betriebssystem auf
    (Windows 11 Pro, alle Update aktuell)

    Ich habe heute Morgen den SQL-Server Express 2017 noch einmal installiert und vorher bzw. während der Installation drei Fehlerquellen gefunden und behoben.

    1. Die Formatierung der David Partition D: war 4K statt 64 k Blockgröße.
      Mit der kleinen Blockgröße haben SQL-Server gemäß Web-Veröffentlichungen manchmal Probleme.
      Lösung: David Dienste gestoppt, alle Daten der Partition auf andere Disk kopiert.
      D: NTFS formatiert mit 64K Blockgröße
      Daten inkl. David-Verzeichnis wiederhergestellt.
    2. "Grant Perform Volume Maintenance Task"
      Sollte aktiviert sein, andernfalls Perfomance Probleme
    3. Der SQL Server-Browser-Dienst muss mit installiert und automatisch gestartet sein

    Dabei ist die zu kleine Blockgröße wohl die wichtigste Einflussgröße, denn der Fehler trat auch bei Verwendung der normalen Installationsroutine von David auf. CoPilot hatte diese Fehlerursache angezeigt ohne eine brauchbare Lösung vorzuschlagen außer Neuinstallation des Betriebssystems. Glücklicherweise hatte ich David auf einer separaten Partition installiert.

    Hardware ist ein Wortmann PC Mini 6000 6.1 mit vorinstalliertem Windows 11 Pro.
    ... "Öfter mal was neues". Dieses SQL Problem hatte ich so in den letzten 16 Jahren noch nicht erlebt.

    Vielen Dank an Euch für die Hilfe.

  • Es tritt noch ein Schönheitsfehler namens SQL Error 80004005 nach 15 Minunten Betriebszeit auf. Die SQL-Suche funktioniert trotzdem.

    Die KI schlägt dazu folgenden Lösungsweg vor:
    Der SQL Error 80004005 ist ein allgemeiner Verbindungskonflikt („Unbekannter Fehler / Zugriff verweigert“).

    Dass der Fehler erst nach exakt 15 Minuten auftritt, liefert den entscheidenden Hinweis: [1]

    Zu diesem Zeitpunkt greift das automatische Energie- oder Standby-Management des SQL Server Express, oder die Integrität des neu aufgebauten Suchindexes bricht ab. Da die Suche anfangs lief, sind die Zugriffsrechte korrekt, aber die Verbindung wird nach Inaktivität getrennt. [1]

    Gehen Sie die folgenden drei Lösungsschritte durch, um den Fehler dauerhaft zu beheben:

    1. Das „Auto-Close“-Feature im SQL Server deaktivieren (Hauptursache)

    Der SQL Server Express hat eine Standardeinstellung namens AUTO_CLOSE. Wenn 15 Minuten lang keine Suchanfrage erfolgt, fährt der SQL Server die Datenbank im Hintergrund herunter, um RAM zu sparen. Tobit David verliert die Verbindung und meldet den Fehler 80004005.

    1. Starten Sie das SQL Server Management Studio (SSMS).
    2. Verbinden Sie sich mit Ihrer Instanz (z. B. .\DAVID).
    3. Klicken Sie im linken Objekt-Explorer auf das Pluszeichen bei Datenbanken.
    4. Machen Sie einen Rechtsklick auf die David-Suchdatenbank (meistens David_Search oder ähnlich benannt) und wählen Sie Eigenschaften.
    5. Wechseln Sie links auf die Seite Optionen.
    6. Suchen Sie in der Liste den Punkt Automatisch schließen (AUTO_CLOSE).
    7. Stellen Sie diesen Wert unbedingt von True auf False.
    8. Klicken Sie auf OK. [1]

    Wiederholen Sie dies zur Sicherheit auch für die Systemdatenbank model.

    2. Die Volltextdatenbank in David zurücksetzen

    Durch die Neuinstallation des SQL-Servers passen die alten Index-Tabellen oft nicht mehr zum neuen Dienst, was nach einigen Minuten Laufzeit zu Abbruchen führt. [1]

    1. Öffnen Sie den David.Administrator (dvadmin.exe).
    2. Navigieren Sie im linken Baum zu System -> Datenbanken.
    3. Machen Sie einen Rechtsklick auf die Volltextdatenbank und wählen Sie Zurücksetzen.
    4. Starten Sie anschließend die Windows-Dienste SQL Server (DAVID) und David Service Layer einmal neu.
    5. David baut den Index nun im Hintergrund sauber und fehlerfrei neu auf. [1]

    3. Energiesparmodus der Netzwerkkarte / SSD prüfen

    Falls die SQL-Instanz über die IP-Adresse oder ein virtuelles Netzwerkinterface angesprochen wird, trennt Windows nach 15 Minuten Inaktivität manchmal die Verbindung:

    1. Öffnen Sie den Windows-Geräte-Manager.
    2. Machen Sie einen Rechtsklick auf Ihre Netzwerkkarte -> Eigenschaften.
    3. Prüfen Sie den Reiter Energieverwaltung.
    4. Deaktivieren Sie die Option: „Computer kann das Gerät ausschalten, um Energie zu sparen“.

    Probieren Sie als Erstes das Abschalten von AUTO_CLOSE im SSMS. Bitte lassen Sie mich wissen:

    • Konnten Sie die Option AUTO_CLOSE in der David-Datenbank finden und auf False umstellen?
    • Tritt der Fehler nach dem anschließenden Dienste-Neustart weiterhin auf?
  • Meine zwei Datenbanken heißen "David Archive Database" und "David TeamBoards Database" und "Automatisch schließen" ist bei beiden "False".

    War das echt aktiv? Vielleicht wird das beim Setup nur aktiviert, wenn es kein Server-Betriebssystem ist?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!