HAL_INITIALIZATION_FAILED BSoD

181951 · Jan 28, 2024

Hi there, it's me again

I've been making a lot of threads lately because no matter how much I learn, I keep coming across new things. I couldn't find much information about the error code above, in a thread on the forum years ago it says that it indicates hardware problems, but I don't think this is the case with the file and computer I have.

When I entered the devnode address in the stack section with the !devnode command, I caught the culprit.

So far so good, I'm confused by the part where I can't find any problems with the graphics card even though I've done all the hardware tests. Could it be that this error code is not entirely hardware related? What exactly is it?

012824-8765-01.rar - Here is the DMP file, I would be grateful if you could analyze it and write down what I didn't see.

Code:

7: kd> !devnode ffffba8fd7fc2bf0
DevNode 0xffffba8fd7fc2bf0 for PDO 0xffffba8fd7f50060
  Parent 0xffffba8fd7f4fca0   Sibling 0000000000   Child 0000000000  
  InterfaceType 0  Bus Number 0
InstancePath is "PCI\VEN_10DE&DEV_25A2&SUBSYS_132E1462&REV_A1\4&b48410e&0&0008"
  ServiceName is "nvlddmkm"

Code:

HAL_INITIALIZATION_FAILED (5c)
Arguments:
Arg1: 0000000000007000
Arg2: 0000000000000020
Arg3: fffff7f280012170
Arg4: ffffdf0be3176de0

Debugging Details:
------------------
ffffba8fe713f890: Unable to read TableSize for resource

ffffba8fe713f890: Unable to read TableSize for resource
*** WARNING: Unable to verify timestamp for win32k.sys

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 1499

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 10374

    Key  : Analysis.Init.CPU.mSec
    Value: 156

    Key  : Analysis.Init.Elapsed.mSec
    Value: 4393

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 85

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1

FILE_IN_CAB:  012824-8765-01.dmp

BUGCHECK_CODE:  5c

BUGCHECK_P1: 7000

BUGCHECK_P2: 20

BUGCHECK_P3: fffff7f280012170

BUGCHECK_P4: ffffdf0be3176de0

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

LOCK_ADDRESS:  fffff80538244c40 -- (!locks fffff80538244c40)

Resource @ nt!PiEngineLock (0xfffff80538244c40)    Exclusively owned
    Contention Count = 18
     Threads: ffffba8fe7ccd040-01<*>
1 total locks

PNP_TRIAGE_DATA:
    Lock address  : 0xfffff80538244c40
    Thread Count  : 1
    Thread address: 0xffffba8fe7ccd040
    Thread wait   : 0x36def

STACK_TEXT:
ffffdf0b`e3176d98 fffff805`37ae19b3     : 00000000`0000005c 00000000`00007000 00000000`00000020 fffff7f2`80012170 : nt!KeBugCheckEx
ffffdf0b`e3176da0 fffff805`37ac5c2d     : 00000000`00000000 00000000`00000000 00000000`00000000 ffff74fa`00000000 : nt!IvtUpdateRemappingTableEntry+0x183
ffffdf0b`e3176e20 fffff805`37978839     : ffffa903`c1554288 ffffdf0b`e3176f19 00000000`3fffffff 00000000`3fffffff : nt!HalpIommuUpdateRemappingTableEntry+0x79
ffffdf0b`e3176e80 fffff805`37d625b9     : 00000000`00000001 ffffdf0b`00000000 ffffdf0b`e3177028 fffff805`37d61000 : nt!HalpInterruptRemap+0x189
ffffdf0b`e3176f70 fffff805`3a5b5ad7     : ffffa903`c1554240 ffffdf0b`e3176fe9 fffff805`3a5a1620 ffffa903`b400cbb0 : nt!HaliAddInterruptRemapping+0x39
ffffdf0b`e3176fb0 fffff805`3a5b3788     : fffff805`3a5a1620 fffff805`3a5a1620 00000000`00000000 fffff805`3a5a1620 : ACPI!IrtRemapNewMsiAssignments+0x107
ffffdf0b`e3177050 fffff805`3a5c1340     : ffffba8f`d78fe000 00000000`00000000 00000000`00000000 fffff805`3a5a1620 : ACPI!IrqArbCommitAllocation+0x198
ffffdf0b`e31770d0 fffff805`37d4fc27     : ffffa903`b400c468 ffffdf0b`e3177170 00000000`00000001 ffffa903`bdcde530 : ACPI!ArbArbiterHandler+0x100
ffffdf0b`e3177110 fffff805`37d4d62d     : ffffa903`bdcde570 00000000`00000000 ffffa903`bdcde530 00000000`00000001 : nt!IopCommitConfiguration+0x47
ffffdf0b`e3177140 fffff805`37d4d1c5     : ffffa903`bdcde570 ffffa903`bdcde530 ffffa903`00000001 00000000`00000000 : nt!PnpAllocateResources+0x3a5
ffffdf0b`e31771b0 fffff805`37d3c142     : 00000000`00000040 ffffba8f`d7f50060 00000000`00000000 fffff805`00000000 : nt!PnpAssignResourcesToDevices+0x55
ffffdf0b`e3177240 fffff805`37d3958f     : ffffdf0b`e31773b0 ffffdf0b`e3177311 00000000`e7b97700 00000000`00000000 : nt!PnpProcessAssignResources+0x126
ffffdf0b`e3177290 fffff805`37d3401a     : ffffba8f`d7fc2b00 ffffba8f`e7b97700 ffffdf0b`e31773b0 fffff805`00000000 : nt!PipProcessDevNodeTree+0xbb
ffffdf0b`e3177360 fffff805`3796f13a     : 00000001`00000003 ffffba8f`d7fc2bf0 00000000`00000000 ffffba8f`e7b977c0 : nt!PiRestartDevice+0xba
ffffdf0b`e31773b0 fffff805`378c46b5     : ffffba8f`e7ccd040 ffffba8f`d68cece0 fffff805`38243440 fffff805`00000000 : nt!PnpDeviceActionWorker+0x46a
ffffdf0b`e3177470 fffff805`379078e5     : ffffba8f`e7ccd040 00000000`00000080 ffffba8f`d688c1c0 001fe4ff`bd9bbfff : nt!ExpWorkerThread+0x105
ffffdf0b`e3177510 fffff805`37a064b8     : ffff9500`745d7180 ffffba8f`e7ccd040 fffff805`37907890 00000057`000004df : nt!PspSystemThreadStartup+0x55
ffffdf0b`e3177560 00000000`00000000     : ffffdf0b`e3178000 ffffdf0b`e3171000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28

SYMBOL_NAME:  ACPI!IrtRemapNewMsiAssignments+107

MODULE_NAME: ACPI

IMAGE_NAME:  ACPI.sys

IMAGE_VERSION:  10.0.19041.3570

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  107

FAILURE_BUCKET_ID:  0x5C_HAL_INTERRUPT_REMAPPING_SETUP_FAILURE_ACPI!IrtRemapNewMsiAssignments

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {e215d9e0-a34d-caa6-13e1-3bdaba6f3ca9}

Followup:     MachineOwner

x BlueRobot · Jan 29, 2024

This is more related to allocation of hardware resources to a device rather than the hardware itself. Do you have a kernel memory dump (MEMORY.DMP) for this? You're going to have to use !arbiter or !arbinst to have any chance of getting any useful information as to why the interrupt remapping failed.

181951 · Jan 29, 2024

x BlueRobot said:
This is more related to allocation of hardware resources to a device rather than the hardware itself. Do you have a kernel memory dump (MEMORY.DMP) for this? You're going to have to use !arbiter or !arbinst to have any chance of getting any useful information as to why the interrupt remapping failed.

Don't have MEMORY.DMP, because this device have has BSoD only once. This is the only file that was created. I tried the !Arbiter command but it didn't give me any results and I don't know exactly what I'm using it for.

x BlueRobot · Jan 29, 2024

hountybunter said:
Don't have MEMORY.DMP, because this device have has BSoD only once.

It should still be available under %systemroot%\MEMORY.DMP unless its has been deleted?

hountybunter said:
I tried the !Arbiter command but it didn't give me any results

It won't because you'll need a full kernel memory dump in order for it to work; a Minidump only contains a small snapshot of memory at the time of the crash so many commands will not work due to much of the data not being present in the dump file.

181951 · Jan 29, 2024

x BlueRobot said:
It should still be available under %systemroot%\MEMORY.DMP unless its has been deleted?

The device I have doesn't even have a MEMORY.DMP folder.I think it's a driver problem as I'm completely guessing. I've had it since yesterday and haven't had any problems, all I've done is uninstall and reinstall the driver with DDU.

181951 · Jan 29, 2024

x BlueRobot said:
It won't because you'll need a full kernel memory dump in order for it to work; a Minidump only contains a small snapshot of memory at the time of the crash so many commands will not work due to much of the data not being present in the dump file.

Yes, I see. If there is no plugin for that, should I force the device to BSoD for now? * NotMyFault - Sysinternals

x BlueRobot · Jan 29, 2024

hountybunter said:
The device I have doesn't even have a MEMORY.DMP folder.

It isn't a folder, it's a file called MEMORY.DMP which should exist under C:\Windows (%systemroot%). The full path would be: C:\Windows\MEMORY.DMP. I would check that the crash dump settings have been set correctly:

Rich (BB code):

reg query "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl"

The CrashDumpEnabled key value should have a data value of 0x7 on Windows 10. I believe it is the same for Windows 11 machines.

hountybunter said:
I think it's a driver problem as I'm completely guessing.

Possibly or a UEFI issue but more likely to be driver related.

hountybunter said:
If there is no plugin for that, should I force the device to BSoD for now?

No, NotMyFault is just a training tool which deliberately generates certain bugchecks for learning purposes.

181951 · Jan 29, 2024

x BlueRobot said:
It isn't a folder, it's a file called MEMORY.DMP which should exist under C:\Windows (%systemroot%). The full path would be: C:\Windows\MEMORY.DMP. I would check that the crash dump settings have been set correctly:

I know there are no folders, but I only have the minidump file in the specified file path. (C:\Windows)

x BlueRobot said:
The CrashDumpEnabled key value should have a data value of 0x7 on Windows 10. I believe it is the same for Windows 11 machines.

I will take a look.

x BlueRobot said:
Possibly or a UEFI issue but more likely to be driver related.

I guess I need to check the device for a few more days and make sure.

x BlueRobot said:
No, NotMyFault is just a training tool which deliberately generates certain bugchecks for learning purposes.

Got it, thank you. Thank you for your help. You've taught me a lot of things.

x BlueRobot · Jan 29, 2024

hountybunter said:
I will take a look.

It should look similar to:

Rich (BB code):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
    AutoReboot    REG_DWORD    0x1
    CrashDumpEnabled    REG_DWORD    0x7
    DumpFile    REG_EXPAND_SZ    %SystemRoot%\MEMORY.DMP
    DumpLogLevel    REG_DWORD    0x0
    EnableLogFile    REG_DWORD    0x1
    LogEvent    REG_DWORD    0x1
    MinidumpDir    REG_EXPAND_SZ    %SystemRoot%\Minidump
    MinidumpsCount    REG_DWORD    0x5
    Overwrite    REG_DWORD    0x0
    DumpFilters    REG_MULTI_SZ    MfeEpeHb.sys\0dumpfve.sys
    AlwaysKeepMemoryDump    REG_DWORD    0x0

hountybunter said:
I guess I need to check the device for a few more days and make sure.

If it does crash then you'll want to check the MEMORY.DMP rather than the Minidump(s). That's assuming it crashes with the same bugcheck code.

hountybunter said:
Thank you for your help.

No problem, glad to be able to help again.

181951 · Jan 29, 2024

x BlueRobot said:

It should look similar to:

Rich (BB code):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
AutoReboot REG_DWORD 0x1
CrashDumpEnabled REG_DWORD 0x7
DumpFile REG_EXPAND_SZ %SystemRoot%\MEMORY.DMP
DumpLogLevel REG_DWORD 0x0
EnableLogFile REG_DWORD 0x1
LogEvent REG_DWORD 0x1
MinidumpDir REG_EXPAND_SZ %SystemRoot%\Minidump
MinidumpsCount REG_DWORD 0x5
Overwrite REG_DWORD 0x0
DumpFilters REG_MULTI_SZ MfeEpeHb.sys\0dumpfve.sys
AlwaysKeepMemoryDump REG_DWORD 0x0

MEMORY.DMP LogEvent key is 0x0 for me. What I need to do here is to set the key value to 1? If I change this, is it guaranteed that the MEMORY.DMP file will be created in case of a crash?

x BlueRobot · Jan 29, 2024

That value determines if information is written to the event log, I would set it to enabled as it can be very useful when you're trying to troubleshoot why no dump files are being written despite crashes.

Rich (BB code):

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl /v LogEvent /t REG_DWORD /d 0x1 /f

It's the same as this:

x BlueRobot · Jan 29, 2024

hountybunter said:
If I change this, is it guaranteed that the MEMORY.DMP file will be created in case of a crash?

No, you'll need to make sure there is adequate free space on the disk as well otherwise no MEMORY.DMP will be written. It tends to be a couple of GB.

181951 · Jan 29, 2024

x BlueRobot said:
That value determines if information is written to the event log, I would set it to enabled as it can be very useful when you're trying to troubleshoot why no dump files are being written despite crashes.

Rich (BB code):

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl /v LogEvent /t REG_DWORD /d 0x1 /f

It's the same as this:

View attachment 96830

I got it and I changed it. If the computer crashes again, I'll look for MEMORY.DMP.

x BlueRobot said:
No, you'll need to make sure there is adequate free space on the disk as well otherwise no MEMORY.DMP will be written. It tends to be a couple of GB.

I have a laptop with the necessary space. No crashes so far.

Search

Search

HAL_INITIALIZATION_FAILED BSoD

181951

Active member

x BlueRobot

Administrator

181951

Active member

x BlueRobot

Administrator

181951

Active member

181951

Active member

x BlueRobot

Administrator

181951

Active member

x BlueRobot

Administrator

181951

Active member

x BlueRobot

Administrator

x BlueRobot

Administrator

181951

Active member