3

После переустановки Windows 8.1 повторное подключение массива дисковых пространств вызывает BSOD.

У меня есть 3 дисковых массива дисков + отдельный SSD. Я переустановил Windows 8 -> и обновился до 8.1

После установки Windows 8 после первой перезагрузки моя машина перешла в цикл перезагрузки с BSOD. После удаления всех дисков машина работает нормально.

Если я подключу только один диск, без сбоев. Я попытался поместить диски на отдельные контроллеры (у меня есть SATA- контроллеры Intel и ASMedia), и как только я добавляю второй диск, BSOD возвращается (вскоре после инициализации диска).

Я полностью отсталый или есть какой-нибудь способ восстановить массив?

Версии драйверов

Intel: 12.9.0.1001 - 29.10.2013
ASR: 1.3.4.0 - 22 июня 2012 года
spaceport.sys: 6.3.9600.16384 (winblue_rtm.130821-1623) - 30.10.2013 18:38:47?

ошибка

Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL  
file path: C:\WINDOWS\system32\drivers\spaceport.sys

Мини-дамп: https://www.dropbox.com/s/yqtnjxvvdvq2nqq/032914-5109-01.dmp

Ошибка Центра действий Windows

Source
Windows

Summary
Shut down unexpectedly

Date
‎3/‎29/‎2014 7:29 PM

Status
Solution available  (note, the solution isn't actually available)

Problem signature
Problem Event Name: BlueScreen
Code:   d1
Parameter 1:    ffffe0001de00ffe
Parameter 2:    2
Parameter 3:    1
Parameter 4:    fffff8000021dc90
OS version: 6_3_9600
Service Pack:   0_0
Product:    256_1
OS Version: 6.3.9600.2.0.0.256.48
Locale ID:  1033

Extra information about the problem
Bucket ID:  AV_spaceport!LogDecodeEntryHeader

WinDgb (анализировать -v)

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffe0001de00ffe, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff80000597c90, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  ffffe0001de00ffe 

CURRENT_IRQL:  2

FAULTING_IP: 
spaceport!LogDecodeEntryHeader+58
fffff800`00597c90 42884411fe      mov     byte ptr [rcx+r10-2],al

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  System

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

TRAP_FRAME:  ffffd00021fa6610 -- (.trap 0xffffd00021fa6610)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000020000000 rbx=0000000000000000 rcx=00000000179e6000
rdx=00000000179e5000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80000597c90 rsp=ffffd00021fa67a8 rbp=ffffe0000641b000
 r8=00000000000179e5  r9=0000000000000000 r10=ffffe0000641b000
r11=ffffe0000641b000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
spaceport!LogDecodeEntryHeader+0x58:
fffff800`00597c90 42884411fe      mov     byte ptr [rcx+r10-2],al ds:ffffe000`1de00ffe=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff803ee75b7e9 to fffff803ee74fca0

STACK_TEXT:  
ffffd000`21fa64c8 fffff803`ee75b7e9 : 00000000`0000000a ffffe000`1de00ffe 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffffd000`21fa64d0 fffff803`ee75a03a : 00000000`00000001 00000000`000179e6 ffffe000`06ba5000 ffffd000`21fa6610 : nt!KiBugCheckDispatch+0x69
ffffd000`21fa6610 fffff800`00597c90 : fffff800`00597db2 ffffe000`080a1970 00000000`00000000 00000000`00000060 : nt!KiPageFault+0x23a
ffffd000`21fa67a8 fffff800`00597db2 : ffffe000`080a1970 00000000`00000000 00000000`00000060 ffffe000`06ba5000 : spaceport!LogDecodeEntryHeader+0x58
ffffd000`21fa67b0 fffff800`0059ad00 : ffffe000`080a1970 00000000`000e4000 00000000`00000000 ffffe000`06ba5000 : spaceport!LogReadRecordComplete+0x3e
ffffd000`21fa67f0 fffff800`0059933f : 00000000`00001000 ffffe000`080a7d80 0003b497`000000e4 00000000`00000000 : spaceport!LogCoreReadDataRecord+0x1d8
ffffd000`21fa6860 fffff800`0058f3f5 : ffffe000`080a7d80 ffffe000`0807b910 0003b497`000000e4 00000000`00000006 : spaceport!SlLogReadLogRecord+0x1a7
ffffd000`21fa68e0 fffff800`00587032 : ffffe000`080a7d80 ffffe000`00000000 ffffe000`07457c18 00000000`00000000 : spaceport!SIO_LOG::BuildChildPacketsRead+0x115
ffffd000`21fa6950 fffff800`00586e94 : ffffe000`080a7d80 ffffe000`07457c18 00000000`00000000 ffffe000`0807b910 : spaceport!SIO_DISPATCH::DispatchInternal+0x32
ffffd000`21fa6990 fffff800`0058adca : ffffe000`080a7d80 ffffe000`07457c0d 00000000`00000000 00000000`00000000 : spaceport!SIO_DISPATCH::Dispatch+0x5c
ffffd000`21fa69c0 fffff800`0058707b : ffffe000`080a7bf8 00000000`00000000 00000000`00000000 00000000`00000000 : spaceport!SIO_RAID::DispatchChildPacket+0xd6
ffffd000`21fa69f0 fffff800`00586e94 : ffffe000`0807bc00 ffffe000`07457c0d 00000000`00000000 ffffe000`07449a00 : spaceport!SIO_DISPATCH::DispatchInternal+0x7b
ffffd000`21fa6a30 fffff800`005889f3 : ffffe000`0807bc78 ffffe000`07457cc0 ffffe000`0807bed0 00000000`00000001 : spaceport!SIO_DISPATCH::Dispatch+0x5c
ffffd000`21fa6a60 fffff800`0058830a : ffffe000`0807bf28 ffffd000`21fa6ae0 ffffe000`039f2650 ffffe000`0807bed0 : spaceport!SIO_DESTAGE::RefillReplay+0x17f
ffffd000`21fa6aa0 fffff800`0058730e : fffff800`005872d8 ffffe000`039f2650 ffffe000`039f2650 ffffe000`05883880 : spaceport!SIO_DESTAGE::Run+0x2b2
ffffd000`21fa6b10 fffff803`ee6a31b9 : fffff800`005872d8 ffffd000`21fa6bd0 ffffe000`039f2650 ffffe000`0669e820 : spaceport!SioTaskWorkerRoutine+0x36
ffffd000`21fa6b50 fffff803`ee68f2e4 : ffffd000`207e8340 ffffe000`05883880 ffffe000`05883880 ffffe000`003b2900 : nt!ExpWorkerThread+0x2b5
ffffd000`21fa6c00 fffff803`ee7562c6 : ffffd000`207dc180 ffffe000`05883880 ffffd000`207e8340 bbb643fc`01d4ab98 : nt!PspSystemThreadStartup+0x58
ffffd000`21fa6c60 00000000`00000000 : ffffd000`21fa7000 ffffd000`21fa1000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
spaceport!LogDecodeEntryHeader+58
fffff800`00597c90 42884411fe      mov     byte ptr [rcx+r10-2],al

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  spaceport!LogDecodeEntryHeader+58

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: spaceport

IMAGE_NAME:  spaceport.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  52718a77

IMAGE_VERSION:  6.3.9600.16452

BUCKET_ID_FUNC_OFFSET:  58

FAILURE_BUCKET_ID:  AV_spaceport!LogDecodeEntryHeader

BUCKET_ID:  AV_spaceport!LogDecodeEntryHeader

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:av_spaceport!logdecodeentryheader

FAILURE_ID_HASH:  {1ed79302-c2e8-c1d4-cadf-6637f8d3ad77}

Followup: MachineOwner

1 ответ1

0

Мне не удалось получить исправление от Microsoft, но я восстановил файлы, выполнив следующие действия:

  • Используя Powershell, установите для VirtualDisk не автоматическое монтирование: Set-VirtualDisk -FriendlyName "BadDisk" -IsManualAttach $True
  • Физически подключите все диски (BSOD - при инициализации VirtualDisk)
  • Загрузите и используйте Reclaime File Recovery и воспользуйтесь демонстрационной версией Recovery Spaces Recovery (обратите внимание, мне пришлось заплатить только за Relclaime, чтобы восстановить файлы).

На отдельном диске скопируйте все файлы с поврежденного VirtualDisk, а затем удалите его.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .