BSOD on creation Pool #434
Comments
|
Would it be possible for you to paste the stack from memory.dmp, or provide memory.dmp file itself? |
|
In case @Armin-windows is a newbie, location of the dump file: |
|
There is also a BlueScreenView tool showing the collected minidumps, FWIW. |
|
That looks interesting, I will give it a go and see how it is to use. |
|
I hope The File helps you.
Greetings
Von: Jorgen Lundman ***@***.***>
Gesendet: Mittwoch, 5. Februar 2025 23:04
An: openzfsonwindows/openzfs ***@***.***>
Cc: Armin-windows ***@***.***>; Author ***@***.***>
Betreff: Re: [openzfsonwindows/openzfs] BSOD on creation Pool (Issue #434)
Would it be possible for you to paste the stack from memory.dmp, or provide memory.dmp file itself?
—
Reply to this email directly, view it on GitHub <#434 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPF5KQB2B7TFFV46DESE3WL2OKDGJAVCNFSM6AAAAABWQ26OH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZYGEZTIOJQGI> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/BPF5KQCNHK3PCGD22WEUPHD2OKDGJA5CNFSM6AAAAABWQ26OH2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTU5H27HM.gif> Message ID: ***@***.*** ***@***.***> >
…--
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com
|
|
i tried it with rc3 ---BSOD direct after install. Here some Dumps 020625-17437-01.dmp |
|
020625-17437-01.dmp 020625-17562-01.dmp 020625-18453-01.dmp Might have just called OpenZFS, hard to tell, can't get at cbuf 020625-17968-01.dmp Might be closing a Handle held by OpenZFS, hard to tell. Can't get to cbuf. Biggest issue here is the memory.dmp are tiny, needs to be kernel pages so we can at least get to cbuf. |
|
Hello, i have some new dumps. 020825-16453-01.dmp Greetings Armin |
|
When trying to install RC4, a BSOD occurs at the end of the installation process. |
|
Sadly, there isn't much I can see with the minidumps. Since it is memory corruption, it happens earlier, before the stack in the dump, and the only clues would be from cbuf. |
|
193 / 5.000 |
|
Or change dump size to kernel pages? |
|
OK. I switched to Kernel. |
|
It's the volume_close problem in that one, I have added some temporary debug code that will skip releasing it if it is already 0. Be nice to know why volume_close is called more than volume_create though. Check rc5. Also, the dump size need to go up one more, now variables are available, but not what they point to :) |
|
ok, I tried it with the RC5. After zpool create came BSOD with Kernel mode Heap Corruption but without any reference to the openzfs.sys driver. Unfortunately after all these errors no dump file is written. |
|
Hello, today I managed to get a dumpfile from a crash. BSOD after |
|
************* Preparing the environment for Debugger Extensions Gallery repositories ************** -- Configuring repositories
************* Waiting for Debugger Extensions Gallery to Initialize **************
Microsoft (R) Windows Debugger Version 10.0.27725.1000 AMD64 Loading Dump File [C:\Windows\MEMORY.DMP] Primary dump contents written successfully ************* Path validation summary **************
SYSTEM_SERVICE_EXCEPTION (3b) Debugging Details:KEY_VALUES_STRING: 1 BUGCHECK_CODE: 3b BUGCHECK_P1: 80000003 BUGCHECK_P2: fffff8025f5d1180 BUGCHECK_P3: ffffec00ea056880 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP DUMP_FILE_ATTRIBUTES: 0x21000 FAULTING_THREAD: ffff80884a275080 CONTEXT: ffffec00ea056880 -- (.cxr 0xffffec00ea056880) BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 PROCESS_NAME: vds.exe STACK_TEXT: SYMBOL_NAME: OpenZFS+1180 MODULE_NAME: OpenZFS IMAGE_NAME: OpenZFS.sys STACK_COMMAND: .cxr 0xffffec00ea056880 ; kb BUCKET_ID_FUNC_OFFSET: 1180 FAILURE_BUCKET_ID: 0x3B_80000003_OpenZFS!unknown_function OS_VERSION: 10.0.26100.1 BUILDLAB_STR: ge_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {e273c5ca-07fc-3f9b-bbbd-cf9f0ae286b1} Followup: MachineOwner
|
|
Yeah, very close to full details, OpenZFS+0x12345 should of course be a resolved name, if you point it to the symbol files, in C:/Program Files/OpenZFS on Windows/symbols usually done by adding that to the |
Another |
|
If you can save the cbuf it would help here, I usually use:
Assuming you have a C:/src It would be easy to not release the usecount if its 0, but that isn't the solution, we track it for a reason, so we shouldnt get more close than create. |
|
Hi, ihave a new Dump File. .writemem C:\src\cbuf.txt poi(OpenZFS!cbuf) L100000 was not possible 18: kd> .writemem E:\cbuf.txt poi(OpenZFS!cbuf) L100000
BUGCHECK_CODE: 3b BUGCHECK_P1: 80000003 BUGCHECK_P2: fffff8053fd61180 BUGCHECK_P3: fffffe016b27d620 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP ADDITIONAL_DEBUG_TEXT: WRONG_SYMBOLS_TIMESTAMP: 2c2d16b3 WRONG_SYMBOLS_SIZE: 144f000 FAULTING_MODULE: fffff80598600000 nt FAULTING_THREAD: ffffa887c488d080 CONTEXT: fffffe016b27d620 -- (.cxr 0xfffffe016b27d620) BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXWINLOGON: 1 STACK_TEXT: FAULTING_SOURCE_LINE: C:\src\openzfs\module\os\windows\spl\spl-err.c FAULTING_SOURCE_FILE: C:\src\openzfs\module\os\windows\spl\spl-err.c FAULTING_SOURCE_LINE_NUMBER: 84 FAULTING_SOURCE_CODE: STACK_COMMAND: .cxr 0xfffffe016b27d620 ; kb EXCEPTION_CODE_STR: 2C2D16B3 EXCEPTION_STR: WRONG_SYMBOLS PROCESS_NAME: ntoskrnl.wrong.symbols.exe IMAGE_NAME: ntoskrnl.wrong.symbols.exe MODULE_NAME: nt_wrong_symbols SYMBOL_NAME: nt_wrong_symbols!2C2D16B3144F000 FAILURE_BUCKET_ID: WRONG_SYMBOLS_X64_26100.1.amd64fre.ge_release.240331-1435_TIMESTAMP_930627-034035_2C2D16B3_nt_wrong_symbols!2C2D16B3144F000 OS_VERSION: 10.0.26100.1 BUILDLAB_STR: ge_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {d3ef0df0-b72f-27fa-b920-f6dc7fcda38b} Followup: MachineOwner
|
|
after BUGCHECK_CODE: 3b BUGCHECK_P1: 80000003 BUGCHECK_P2: fffff8053fd61180 BUGCHECK_P3: fffffe016b27d620 BUGCHECK_P4: 0 FILE_IN_CAB: MEMORY.DMP FAULTING_THREAD: ffffa887c488d080 CONTEXT: fffffe016b27d620 -- (.cxr 0xfffffe016b27d620) BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXWINLOGON: 1 PROCESS_NAME: FancyCcV.exe STACK_TEXT: FAULTING_SOURCE_LINE: C:\src\openzfs\module\os\windows\spl\spl-err.c FAULTING_SOURCE_FILE: C:\src\openzfs\module\os\windows\spl\spl-err.c FAULTING_SOURCE_LINE_NUMBER: 84 FAULTING_SOURCE_CODE: SYMBOL_NAME: OpenZFS!spl_panic+70 MODULE_NAME: OpenZFS IMAGE_NAME: OpenZFS.sys STACK_COMMAND: .cxr 0xfffffe016b27d620 ; kb BUCKET_ID_FUNC_OFFSET: 70 FAILURE_BUCKET_ID: 0x3B_80000003_OpenZFS!spl_panic OS_VERSION: 10.0.26100.1 BUILDLAB_STR: ge_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {acbef694-3392-c1df-dde9-ff3eb6775309} Followup: MachineOwner
|
|
@Armin-windows 44 minutes ago:
Heck is that messed up. |
|
Hi sskras |
|
All fine, me too, and no need to be one! :) if in future you could add two Thanks in advance! :) |
020625-17578-01.dmp
Openzfs for Windows 2.3.0 RC2
Windows 11 Pro
24H2
26100.3037
after zpool create tank PHYSICALDRIVE4 BSOD from zpool.sys.
with 23h2 its ok.
after trying to import the Tank created on 23H2 to 24H2 the same BSOD.
no creation or import Pool possible.
can you help me?
Greetings Armin
I hope the Dump File helps......
The text was updated successfully, but these errors were encountered: