[SOLVED] What is the OfflineUniqueIDEKPub context?

Brokoliy

Member
Joined
Jul 8, 2024
Posts
12
I'm analysing a file, I've never actually looked at the memory.dmp dump, I just see this context in the !dpx output of every minidump. Variables are being transferred from a device to the HAL layer and the system crashes. It's the same and the same. What exactly is the explanation for this?

Rich (BB code):
6: kd> !dpx
Start memory scan  : 0xfffffa8a1d8b4268 ($csp)
End memory scan    : 0xfffffa8a1d8b5000 (Kernel Stack Base)

               rsp : 0xfffffa8a1d8b4268 : 0xfffff80254e2ad29 : nt!KiBugCheckDispatch+0x69
               r14 : 0xfffffa8a1d8b4690 :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b4268 : 0xfffff80254e2ad29 : nt!KiBugCheckDispatch+0x69
0xfffffa8a1d8b4398 : 0xfffffa8a1d8b4690 :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b43a8 : 0xfffff80254e26189 : nt!KiPageFault+0x489
0xfffffa8a1d8b43b0 : 0x00000085eeefdd70 :  Trap @ fffffa8a1d8b43b0
0xfffffa8a1d8b43c8 : 0xfffff80254cb6125 : nt!KiUpdateNodeAffinitizedFlag+0x15
0xfffffa8a1d8b4580 : 0xfffffa8a1d8b4690 :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b45e8 : 0xfffff80254c0be5f : nt!KeSetSystemGroupAffinityThread+0xff
0xfffffa8a1d8b4610 : 0xfffffa8a1d8b4690 :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b4618 : 0xfffff80254d52234 : nt!HalEfiGetEnvironmentVariable+0x58
0xfffffa8a1d8b4620 : 0xfffffa8a1d8b4690 :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b4658 : 0xfffff80254d5219e : nt!HalGetEnvironmentVariableEx+0x10e
0xfffffa8a1d8b4678 : 0xfffff802551c6cf0 : nt!IopGetEnvironmentVariableHal
0xfffffa8a1d8b4688 : 0xfffff80254d52123 : nt!HalGetEnvironmentVariableEx+0x93
0xfffffa8a1d8b4690 : 0x006c00660066004f :  !du "OfflineUniqueIDEKPub"
0xfffffa8a1d8b4698 : 0x00550065006e0069 :  !du "ineUniqueIDEKPub"
0xfffffa8a1d8b46a0 : 0x007500710069006e :  !du "niqueIDEKPub"
0xfffffa8a1d8b46a8 : 0x0045004400490065 :  !du "eIDEKPub"
0xfffffa8a1d8b4728 : 0xfffff802551c6d13 : nt!IopGetEnvironmentVariableHal+0x23
0xfffffa8a1d8b4748 : 0xfffff80255282b90 :  !du "\Device\SysEnv"
0xfffffa8a1d8b4768 : 0xfffff8025517ab8c : nt!IoGetEnvironmentVariableEx+0x94
0xfffffa8a1d8b47c8 : 0xfffff80255475770 : nt!IopSysEnvFunctionTableHal
0xfffffa8a1d8b47d8 : 0xfffff80254c5b998 : nt!MmMapLockedPagesSpecifyCache+0x168
0xfffffa8a1d8b4838 : 0xfffff8025517a8ca : nt!ExLockUserBuffer+0xfe
0xfffffa8a1d8b4888 : 0xfffff8025517a996 : nt!ExpGetFirmwareEnvironmentVariable+0x8e
0xfffffa8a1d8b48d8 : 0xfffff80255178d27 : nt!NtQuerySystemEnvironmentValueEx+0x227
0xfffffa8a1d8b49a8 : 0xfffff80254e2a405 : nt!KiSystemServiceCopyEnd+0x25
0xfffffa8a1d8b49d8 : 0xfffff802550cce0d : nt!NtQuerySystemInformation+0x5d
0xfffffa8a1d8b49e8 : 0xfffff802550bbcc9 : nt!NtClose+0x39
0xfffffa8a1d8b4a18 : 0xfffff80254e2a405 : nt!KiSystemServiceCopyEnd+0x25

Dump
 
meaningless, I solved this problem by changing the processor paste. There is one thing I don't understand: What does the TPM key have to do with it? Wasn't it created at 0xD1 IRQL 2 level?
 
yes this is a 0xd1 and the IRQL level is ff, which is 0. 0xd1, as far as I know, occurs in invalid accesses at IRQL level 2. am I wrong? wasn't the IRQL level recorded because it was a minidump? I actually added the minidump files to the thread, but I guess didn't see them. You can see it if you click on the dump link at the bottom.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top