locked
BSOD system_thread_excption_not_handled (WppRecorder.sys) RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    have installed windows 2012 R2,  all have been working fine and installed a Hyper-v server which am have install AD, DNS, DHCP which has been working grate.

    after install an update on virtual server I rebooted and now am receiving a BSOD system_thread_excption_not_handled (WppRecorder.sys)

    and it not allowing me to access anything. 

    I have look into the firmware setting on the virtual server  and noticed file type called bootmgfw.efi on the firmware virtual setting.  which details 

    Description: Windows Boot Manager

    Value: \HD(2,GPTBA6F9016-9039-4EED-95D7-7C9DFDA947F4,77056,66560)\EFI\Microsoft\Boot\bootmgfw.efi

    Firmware device path: \HD(2,GPTBA6F9016-9039-4EED-95D7-7C9DFDA947F4,77056,66560)\EFI\Microsoft\Boot\bootmgfw.efi

    am using a physical hard disk which I have created using virtual disks which is offline and I have other Hyper-v Virtual server which are using the same settings and it working fine.

    can anyone help me with this issue?

    Many thanks,

    PJ

    PJ Moka

    Thursday, October 24, 2013 5:14 PM

Answers

  • Question
    Sign in to vote
    8
    Sign in to vote

    This looks like a known bug related to 4KB-sector ('Advanced Format') disk drives and NTFS compression.

    The updated servicing stack in Windows Server 2012 R2 / Windows 8.1 compresses some rarely used files in c:\windows\WinSxS as a part of CBS (Component Based Servicing) Scavenging process.
    (presumably, this change was introduced in 8.1 due to complaints related to low available disk space on low-end Windows tablet devices, where disk space is tight).

    After you install or remove an update, the CBS Scavenging scheduled task will re-check the WinSXS folder and compress some of the files.

    The problem is that it also compresses some driver files (such as cdrom.sys), and those driver files may be hardlinked to the live copy in system32\drivers folder. As a result, when the CBS Scavenger compresses these files, the actual cdrom.sys file in system32\drivers becomes compressed.

    The compression itself is not the issue, however - Windows will load compressed drivers just fine.
    It turns that the cdrom.sys driver has a bug - it accesses memory past the declared .data section in the driver image.
    The NTFS driver performs the decompression "in place", so the memory that is past the .data section may contain "random" data.

    It turns out that if the sector size is 512 bytes, the bug in cdrom.sys does not lead to a crash, because those "random" bytes are in fact zero.

    However, when using a NTFS volume that is located on a 4KB Advanced Format drive, the bytes past the .data section of cdrom.sys contain (by chance) some bytes from the .pdata section of cdrom.sys.
    And this is precisely what causes the crash right during the DriverEntry of cdrom.sys.

    Workaround:
    1) Boot to the recovery console (you should automatically get there after a few Blue Screen crashes)
    2) Launch command prompt
    3) Run the following command:
    c:\windows\system32\compact.exe /U c:\windows\system32\drivers\*.sys

    4) Reboot
    5) As soon as you successfully boot, disable NTFS compression system-wide so that the CBS Scavenger does not reintroduce the issue again:
    fsutil behavior set DisableCompression 1

    6) Reboot again (so the DisableCompression setting takes effect)

    Files that are compressed will stay compressed (and readable).
    However, CBS Scavenger will be unable to compress the files and cause the issue.

    P.S.
    The cdrom.sys is not the only driver that has this issue - I've also seen nearly identical crashes in intelppm.sys (but they are not 100% reproducible).

    • Proposed as answer by kroyl Thursday, October 24, 2013 6:32 PM
    • Marked as answer by Alex Lv Tuesday, October 29, 2013 9:51 AM
    • Unmarked as answer by PJ Moka Sunday, July 6, 2014 4:36 PM
    • Marked as answer by Hamid Sadeghpour SalehMVP Saturday, January 4, 2020 7:41 PM
    Thursday, October 24, 2013 6:13 PM

All replies

  • Question
    Sign in to vote
    8
    Sign in to vote

    This looks like a known bug related to 4KB-sector ('Advanced Format') disk drives and NTFS compression.

    The updated servicing stack in Windows Server 2012 R2 / Windows 8.1 compresses some rarely used files in c:\windows\WinSxS as a part of CBS (Component Based Servicing) Scavenging process.
    (presumably, this change was introduced in 8.1 due to complaints related to low available disk space on low-end Windows tablet devices, where disk space is tight).

    After you install or remove an update, the CBS Scavenging scheduled task will re-check the WinSXS folder and compress some of the files.

    The problem is that it also compresses some driver files (such as cdrom.sys), and those driver files may be hardlinked to the live copy in system32\drivers folder. As a result, when the CBS Scavenger compresses these files, the actual cdrom.sys file in system32\drivers becomes compressed.

    The compression itself is not the issue, however - Windows will load compressed drivers just fine.
    It turns that the cdrom.sys driver has a bug - it accesses memory past the declared .data section in the driver image.
    The NTFS driver performs the decompression "in place", so the memory that is past the .data section may contain "random" data.

    It turns out that if the sector size is 512 bytes, the bug in cdrom.sys does not lead to a crash, because those "random" bytes are in fact zero.

    However, when using a NTFS volume that is located on a 4KB Advanced Format drive, the bytes past the .data section of cdrom.sys contain (by chance) some bytes from the .pdata section of cdrom.sys.
    And this is precisely what causes the crash right during the DriverEntry of cdrom.sys.

    Workaround:
    1) Boot to the recovery console (you should automatically get there after a few Blue Screen crashes)
    2) Launch command prompt
    3) Run the following command:
    c:\windows\system32\compact.exe /U c:\windows\system32\drivers\*.sys

    4) Reboot
    5) As soon as you successfully boot, disable NTFS compression system-wide so that the CBS Scavenger does not reintroduce the issue again:
    fsutil behavior set DisableCompression 1

    6) Reboot again (so the DisableCompression setting takes effect)

    Files that are compressed will stay compressed (and readable).
    However, CBS Scavenger will be unable to compress the files and cause the issue.

    P.S.
    The cdrom.sys is not the only driver that has this issue - I've also seen nearly identical crashes in intelppm.sys (but they are not 100% reproducible).

    • Proposed as answer by kroyl Thursday, October 24, 2013 6:32 PM
    • Marked as answer by Alex Lv Tuesday, October 29, 2013 9:51 AM
    • Unmarked as answer by PJ Moka Sunday, July 6, 2014 4:36 PM
    • Marked as answer by Hamid Sadeghpour SalehMVP Saturday, January 4, 2020 7:41 PM
    Thursday, October 24, 2013 6:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks a million mate,  I have done everything I could to get this working.  I've tried the option above and it working fine now.  :)

    PJ Moka

    Thursday, October 24, 2013 6:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Glad that it helped :)

    Hopefully, Microsoft will issue a patch for this issue soon (I suspect they've got a ton of these 'WppRecorder.sys' crash dumps by now).

    Thursday, October 24, 2013 6:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Similar issue with vhdmp.sys driver. BSoD during any VHD/VHDX file mounting in Windows (just double-click on virtual disk file) :) the same conditions - 4K-sector... uncompressing vhdmp.sys solves the problem

    Active Directory? Ask me how.

    Tuesday, April 22, 2014 9:26 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hello I am not a geek but I am having the same problem and it will be kind of u if u can explain in easy steps how to fix this error thanks 
    Monday, June 30, 2014 12:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I did this on my Wife windows 8.1 system (Retail Disk install of windows 8.1) about June 12,2014 and just Had to do it again to her system Aug 21,2014.

    5 Files had become Compressed.  I had done the

    Fsutil Behavior set DisableCompression 1

    Command too so I don't know why it would compress the files. But it has done it. Her system is Update it set to AutoUpdate daily. But the same Problem less than two months apart just makes me sad. (Been Lucky on my system I ran the command just to see if any file had compressed I had 0.) I got both of our Retail windows 8.1 install Disk set about 48 hours apart at the Local BestBuy.

    Update 10/14/2014

    Had to re-uncompress again today. Todays Windows Updates(Tuesday Oct 14,2014) had my Wife system have this error again. One of the ".sys" file in the window\system32\drivers file got compressed again. I know it was the update due to the fact we Manually did the Update and the system crashed. (had done a reboot that morning no problem, the window update where the only new item added to the system at all) 


    • Edited by GSWolf74 Tuesday, October 14, 2014 9:42 PM
    • Proposed as answer by Donaldiniosan Friday, May 10, 2019 1:50 AM
    • Unproposed as answer by Donaldiniosan Friday, May 10, 2019 1:51 AM
    Thursday, August 21, 2014 6:15 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    this answer is to hard for me can i just turn off or pick from my updates and it will fix it?

    Wednesday, February 18, 2015 6:28 AM
  • Question
    Sign in to vote
    2
    Sign in to vote
    Microsoft released on-demand hotfix for this issue, I've already tested it - problem solved. Article KB3027108.

    Active Directory? Ask me how.

    • Proposed as answer by AndricoRus Friday, March 6, 2015 2:18 PM
    Friday, March 6, 2015 1:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I like how the KB article is worded like it is a problem with the VHD/VHDX driver (vhdmp.sys) - which is only one of the affected drivers.
    And the changed file is 'ntfs.sys' :)

    During investigation of the crashes, I noticed that all of the affected drivers did actually access data beyond what's allocated according to the PE header of the driver .SYS file.
    And all of the offending code seems to be inserted by an automatic instrumentation library or tool (I believe it is WPP - Windows Trace Preprocessor).

    I believe instead of patching each driver that was instrumented with the broken WPP, Microsoft chose to avoid decompressing the driver files "in place" in the NTFS driver - this was indeed possible on 4K disks because the NTFS file compression unit is 4KB - equal to the sector size of the underlying block device.

    Friday, March 6, 2015 2:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I like how the KB article is worded like it is a problem with the VHD/VHDX driver (vhdmp.sys) - which is only one of the affected drivers.
    And the changed file is 'ntfs.sys' :)

    During investigation of the crashes, I noticed that all of the affected drivers did actually access data beyond what's allocated according to the PE header of the driver .SYS file.
    And all of the offending code seems to be inserted by an automatic instrumentation library or tool (I believe it is WPP - Windows Trace Preprocessor).

    I believe instead of patching each driver that was instrumented with the broken WPP, Microsoft chose to avoid decompressing the driver files "in place" in the NTFS driver - this was indeed possible on 4K disks because the NTFS file compression unit is 4KB - equal to the sector size of the underlying block device.

    It's because I've initially submitted the case to MSPSS due to vhdmp.sys issue I had on VMM server, but the problem is the same.

    Active Directory? Ask me how.

    Friday, March 6, 2015 2:10 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Thanks alot that really saved my bacon!!
    Thursday, August 25, 2016 3:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Can I buy you a beer?! I just had this issue on a production Hyper-V host with Win 2012 R2 and I was freaking out. This solution solved the problem right away. Thanks, mate! You saved me HOURS of work and probably a minor heart attack!
    Wednesday, February 8, 2017 3:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    ótimo post salvou meu dia.

    natã fortunatto

    Sunday, February 17, 2019 1:26 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Glad that it helped :)

    Hopefully, Microsoft will issue a patch for this issue soon (I suspect they've got a ton of these 'WppRecorder.sys' crash dumps by now).

    It's 2019 still got the issue m8 :)
    Friday, May 10, 2019 1:52 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks... it's really worked.
    Monday, February 10, 2020 4:53 AM