[CODE lang="rich" highlight="7"]IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an.
interrupt request level (IRQL) that is too high. This is usually.
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffff8781b3000028, memory referenced.
Arg2: 0000000000000002, IRQL.
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation.
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80037312be9, address which referenced memory.
[/CODE]
ffff8781b3000028 başvurulan belleği ifade ediyor. Ya geçersiz ya da çok yüksek bir kesme seviyesindeydi o durumda.
Rich (BB code):
8: kd> !pte ffff8781b3000028.
VA ffff8781b3000028.
PXE at FFFFAFD7EBF5F878 PPE at FFFFAFD7EBF0F030 PDE at FFFFAFD7E1E06CC0 PTE at FFFFAFC3C0D98000.
contains 0A0000107FFFF863 contains 0A0000107FFFD863 contains 0000000000000000.
pfn 107ffff ---DA--KWEV pfn 107fffd ---DA--KWEV contains 0000000000000000.
not valid.
Bir adres alanındaki dizilerin girişini gösteren! Pte komutumuzu kullanarak normal şartlarda geçerli olması gereken başvurulan adresin geçerli (not valid) olmadığını görebilirsin. Neden geçerli değil? Bunun nedeni bu adresin şu anda Pagefile'da olmasıdır.
Neden sadece direkt olarak Page'e eklenmeme sebebi de Windows bellek yöneticisi - kernel modu ve kuralları ile ilgili olarak bu şekilde çalışmamasından dolayıdır. Eğer kesme seviyesi 2 ya da daha yüksekse hiçbir şeyi sayfalanmaz bu nedenle de bu hatayı alırsın.
Kod:
8: kd> !irql
Debugger saved IRQL for processor 0x8 -- 2 (DISPATCH_LEVEL)
Sistemin neden çöktüğü belli, nasıl çöktüğü de stack kısmında yazıyor:
Rich (BB code):
8: kd> KnL.
# Child-SP RetAddr Call Site.
00 ffffb10b`263e1de8 fffff800`3742de29 nt!KeBugCheckEx
01 ffffb10b`263e1df0 fffff800`37429289 nt!KiBugCheckDispatch+0x69
02 ffffb10b`263e1f30 fffff800`37312be9 nt!KiPageFault+0x489
03 ffffb10b`263e20c0 fffff800`372f34e6 nt!MiResetAccessBitPte+0xb9
04 ffffb10b`263e2120 fffff800`372f38aa nt!MiWalkPageTablesRecursively+0x266
05 ffffb10b`263e21b0 fffff800`372f38aa nt!MiWalkPageTablesRecursively+0x62a
06 ffffb10b`263e2240 fffff800`372f38aa nt!MiWalkPageTablesRecursively+0x62a
07 ffffb10b`263e22d0 fffff800`372f3181 nt!MiWalkPageTablesRecursively+0x62a
08 ffffb10b`263e2360 fffff800`372ab62d nt!MiWalkPageTables+0x371
09 ffffb10b`263e2460 fffff800`372f2875 nt!MiCaptureAndResetWorkingSetAccessBits+0x105
0a ffffb10b`263e2750 fffff800`37215229 nt!MiTrimOrAgeWorkingSet+0x2c5
0b ffffb10b`263e27d0 fffff800`37253b3c nt!MiProcessWorkingSets+0x319
0c ffffb10b`263e2980 fffff800`37392e73 nt!MiWorkingSetManager+0x12c
0d ffffb10b`263e2a40 fffff800`3736d8e7 nt!KeBalanceSetManager+0x2c3
0e ffffb10b`263e2b30 fffff800`3741d0f4 nt!PspSystemThreadStartup+0x57
0f ffffb10b`263e2b80 00000000`00000000 nt!KiStartSystemThread+0x34
Anladığım birkaç iş parçacığı DPC seviyesinde takılı kalıyor çünkü bir bellek alanındaki bitleri bununla beraber sayfaların kontrolünü bekliyorlar. Bu sorun 8.çekirdekte meydana geliyor, buna sebep olan şey bu çekirdekte çalışan bir iş parçacığı da olabilir.
Devam edersek, çöken komutta ne olduğuna da bakabiliyoruz.
Rich (BB code):
.trap 0xffffb10b263e1f30.
rax=ffff878000000000 rbx=0000000000000000 rcx=000000ffffffffff
rdx=ffffafd7ebf5f7f8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80037312be9 rsp=ffffb10b263e20c0 rbp=ffff8781b3000000
r8=0000000000000000 r9=0000009100000073 r10=fffff80037312b30
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc.
nt!MiResetAccessBitPte+0xb9:
fffff800`37312be9 480fba652828 bt qword ptr [rbp+28h],28h ss:0018:ffff8781`b3000028=????????????????
Resetting default scope.
Olan şeyin rbp kaydı artı 0x28'den hesaplanan bellek adresinde bulunan 64 Bit'lik bir değerdeki 40. biti test etmesi. Bu testin sonucu carry Flag'de saklanacak ve programın bu belirli bitin durumuna göre karar vermesini sağlayıyor.
CF için herhangi bir taşma olmadığı söyleniyor.
Rich (BB code):
8: kd> .formats ffff8781b3000000.
Evaluate expression:
Hex: ffff8781`b3000000
Decimal: -132483853058048
Octal: 1777774170066300000000
Binary: 11111111 11111111 10000111 10000001 10110011 00000000 00000000 00000000.
Chars: ........
Time: ***** Invalid FILETIME.
Float: low -2.98023e-008 high -1.#QNAN
Double: -1.#QNAN
8: kd> .formats ffff8781`b3000028
Evaluate expression:
Hex: ffff8781`b3000028
Decimal: -132483853058008
Octal: 1777774170066300000050
Binary: 11111111 11111111 10000111 10000001 10110011 00000000 00000000 00001000.
Chars: .......(
Time: ***** Invalid FILETIME.
Float: low -2.98025e-008 high -1.#QNAN
Double: -1.#QNAN
Fakat 2 adreste 1 bit farkı var. One_bıt RAM sorunlarını işaret ediyor bu Debug analizlerinde. Bu vesileyle kısa sürecek bir testi yapmanı isteyebilirim:
Sistem armourcrate açıkken çökmüş. Sıkıntılı bir uygulama bu sebeple direkt olarak bundan bile kaynaklanıyor olabileceğini de söyleyeyim.
Rich (BB code):
PROCESS ffffe60f42eac080.
SessionId: none Cid: 21dc Peb: 45d5909000 ParentCid: 17ec.
DirBase: 103b4df000 ObjectTable: ffffb20e4dfae140 HandleCount: <Data Not Accessible>
Image: ArmouryCrate.U
ffffb20e4dfae140: Unable to read handle table.