Beiträge von strik im Thema „Erledigt: ntoskrnl "defekt" aber mal was Neues“

    strik: danke für die Infos. Das mit dem Mehrprozessor-Kernels war mir klar, dass die Dateien aber in sich verlinkt sind... naja, ist wohl historisch gewachsen. :bgdev


    Nun ja, es wird vielleicht noch klarer wenn man bemerkt, dass z.B. NTOSKRNL.EXE auch Funktionen wie HalDispatchTable(), HalExamineMBR() und HalPrivateDispatchTable() exportiert, andererseits HAL.DLL folgende Funktionen (XP SP3, fully patched, mit "objdump -x hal.dll" ermittelt, dann unter "Export table" schauen):

    - ExAcquireFastMutex (Ex... = Executive)
    - ExReleaseFastMutex
    - ExTryToAcquireFastMutex

    - IoAssignDriveLetters (Io... = IO Manager, eigentlich Aufgabe des Kernels)
    - IoFlushAdapterBuffers
    - IoFreeAdapterChannel
    - IoFreeMapRegisters
    - IoMapTransfer
    - IoReadPartitionTable
    - IoSetPartitionInformation
    - IoWritePartitionTable

    - KdComPortInUse (Kd... = Kernel Debugger)

    - KeAcquireInStackQueuedSpinLock (Ke... = Kernel)
    - KeAcquireInStackQueuedSpinLockRaiseToSynch
    - KeAcquireQueuedSpinLock
    - KeAcquireQueuedSpinLockRaiseToSynch
    - KeAcquireSpinLock
    - KeAcquireSpinLockRaiseToSynch
    - KeFlushWriteBuffer
    - KeGetCurrentIrql
    - KeLowerIrql
    - KeQueryPerformanceCounter
    - KeRaiseIrql
    - KeRaiseIrqlToDpcLevel
    - KeRaiseIrqlToSynchLevel
    - KeReleaseInStackQueuedSpinLock
    - KeReleaseQueuedSpinLock
    - KeReleaseSpinLock
    - KeStallExecutionProcessor
    - KeTryToAcquireQueuedSpinLock
    - KeTryToAcquireQueuedSpinLockRaiseToSynch

    - KfAcquireSpinLock (Kf... = Kernel)
    - KfLowerIrql
    - KfRaiseIrql
    - KfReleaseSpinLock

    Zu Kf... vs. Ke...: Die Ke... Funktionen werden normalerweise direkt aufgerufen. Die Kf... - Funktionen sind hingegen undokumentiert. Meistens werden sie über dokumentierte Makros aufgerufen. z.B:

    Code
    #define KeLowerIrql(a)      KfLowerIrql(a)
    #define KeRaiseIrql(a,b)    *(b) = KfRaiseIrql(a)


    Man erkennt schon, dass HAL und Kernel stark miteinander verzahnt sind und nicht einfach beliebig austauschbar.

    Zitat

    - Zuerst wird der HAL geladen, korrekt? IIRC sieht das aber im Log andersrum aus. Aber wenn er auf einer Partition keinen Systemdateien findet, dann kommt ja die Fehlermeldung, dass er den HAL net gefunden hat.


    Ich bin kein Spezialist hier. Da aber HAL.DLL und NTOSKRNL.EXE jeweils ohne den andere nicht können, ist die Reihenfolge eigentlich egal. IIRC werden sie beide von NTOSLDR geladen.

    Aha, hier findet sich das: Bitte melde dich an, um diesen Link zu sehen.
    Oder auch hier: Bitte melde dich an, um diesen Link zu sehen.. Beachte, dass der Technet-Artikel zwar angibt, dass der HAL unterschiedlich sein kann, sich über NTOSKRNL aber ausschweigt.

    Zitat


    - Wieso kann er im abgesicherten Modus mit falschem Kernel booten? Nach den oberflächlichen Infos bei MS zu urteilen, verzichtet er doch eigentlich nur auf (spezielle) Gerätetreiber. Aber da scheint ja auch so noch einiges andere nicht geladen zu werden.


    Ich bin nun absolut kein Spezialist für den Safe-Mode, auch sind die Informationen darüber sehr spärlich. Daher kann ich diese Frage nicht beantworten.

    Zitat

    Technet und die Usegroups sind ja mittlerweile auch eher mau geworden in den letzten vier, fünf Jahren. Jedenfalls kommt mir das so vor.

    Nun ja, immer mehr Leute wandern von den Usegroups zu irgend solchen komischen Foren ab. Dort ist allerdings das Rauschen so extrem hoch, dass viele wieder genervt abwandern. Ein Grund mehr, warum ich Foren nicht so mag.

    Gruß
    Spiro

    Nachdem ich die letzen Updates wieder entfernt habe (was nix brachte) und dann den SP3 im abgesicherten Modus reinstalliere, läuft die Kiste wieder. Weiss der Geier, das da klemmte.


    Nur eine Idee: Die NTOSKRNL.EXE Datei ist nicht eindeutig. Es gibt auf der Installations-CD mehrere: ntoskrnl.exe, ntkrnlmp.exe
    ntkrnlpa.exe und ntkrpamp.exe. Bei der Installation wird aufgrund verschiedener Faktoren eine gewählt (z.B. ist ntoskrnl.exe nur mit einem einzigen logischen und physikalischen Prozessor sinnvoll), in WINDOWS\system32 kopiert und in NTOSKRNL.EXE umbenannt!

    Nun muss die NTOSKRNL.EXE auch mit der passenden HAL.DLL genutzt sein. Davon gibt es wiederum einige auf der Installations-CD: hal.dll, halaacpi.dll, halacpi.dll, halapic.dll, halmacpi.dll, halmps.dll, halsp.dll. Auch diese wird kopiert und dann in HAL.DLL umbenannt.

    Die "tatsächlichen" Namen der NTOSKRNL.EXE und HAL.DLL erfährt man übrigens, indem man in den Dateien nach der Zeichenfolge .pdb (klein geschrieben) sucht. Bei der Kompilation vermerkt der Compiler in der Datei, wo die Programmdatenbank (Program Data Base, PDB) zu finden ist - Debugging-Informationen. Daher steht in der ntoskrnl.exe ein Verweis auf die ntoskrnl.pdb, in ntkrnlpa.exe ein Verweis auf ntkrnlpa.pdb, in halacpi.dll ein Verweis auf halacpi.pdb, usw.

    Möglicherweise paßte bei dir die (kopierte) NTOSKRNL.EXE nicht zur HAL.DLL?

    Gruß
    Spiro