Is your filter a boot start driver? I can’t imagine that MSFT would not
load all boot start drivers all the time since they can effect the data
being stored on disk, resulting in a corrupted system partition, etc. if
not loaded.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295
------ Original Message ------
From: xxxxx@digitalguardian.com
To: “Windows File Systems Devs Interest List”
Sent: 5/3/2016 8:52:47 AM
Subject: RE:[ntfsd] minifilter not loaded during some portion of Windows
10 update?
>> What times are you seeing this? Is it during boot processing after
>>you
>> have installed an update?
>
>I’m having an engineer analyze the Windows event logs and procmon to
>hopefully isolate the exact scenario(s) where this happens so that I
>can implement a workaround by knowing when my driver is not going to
>get loaded on next reboot. I’ll share that here once/if I have
>something.
>
>But generally it’s happening during certain boot sequences after
>initiating an update. It’s only on certain updates and they are ones
>that involve multiple boot sequences. The data we have so far indicates
>that it’s only on updates that change the build number of Windows.
>
>Here’s what we observed in a test run:
>
>Begin applying the update
>roughly 3:10pm Portion of windows updates which occur while the system
>is running are complete. User tells the system to reboot to complete
>the updates.
>3:14pm 22% complete with ?working on updates?
>3:17pm Reboot
>3:17pm ?Updating Windows? “black screen” showing % completion ? Files
>are being copied but my driver is not loaded
>3:35pm Reboot ? ?a one-time boot sequence was used during this boot?
>seen in Windows event log, also have Windows event logs indicating ‘the
>boot type was 0x0’, ‘the boot menu policy was 0x1’.
>3:36pm ?Updating Windows? “black screen” ? installing features and
>drivers but my driver is not loaded
>3:42pm Reboot ? Same message about one-time boot sequence, but this
>time my driver is loaded
>3:44pm ?Updating Windows? “black screen” ? Configuring settings and my
>driver is loaded
>3:56pm Reboot?? - actually not sure this was a real reboot, doesn’t
>look like it from the event logs.
>3:59pm Login ? my driver is loaded and everything is normal – except
>that I missed all of the file system modifications in the above phases
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
My filter is set for SYSTEM_START, not BOOT_START. Is it even possible to set a minifilter to be BOOT_START? We’ve been trying to test that but it does not seem possible.
Prior to this new method of updating the OS version in Win10, we’ve never not been loaded so SYSTEM_START seemed to always be working.
My team has been putting together a theory on what’s happening, which I’ll explain back in the original thread, that would imply that no 3rd party drivers are loaded during this phase because Windows is booted from an alternate install disk rather than the normal image on the system.
My team’s research on this has shown the following scenario to be at play:
Windows update in Win10 delivers minor updates much like Win 7/8, but also major updates which rev the version number of the OS and are applied in a new manner, such as the November update to version 1511 OS build 10586. These can be identified by the system going through 3 phases, separated by reboots, of an ‘Updating Windows’ black screen: copying files, installing features and drivers, and configuring settings.
The files for this type of update are staged in C:$Windows.~BT. Within that folder appears to be a Win10 install disk (files setup.exe, bootmgr, and others. folders boot, efi, sources, support and others).
During the first phase, no Windows event logs are gathered and the driver for our product does not load. During the second phase, Windows event logs are gathered but our driver does not load. In the third phase event logs are gathered, and our driver is installed (again) and starts.
The current theory is that in the first and possibly second phases the existing Windows 10 install is not booting at all, instead the system is booting off of the ‘install disk’ in $Windows.~BT
If this is correct, then it would seem that no 3rd party drivers would load in those special phases because Windows is being loaded from that install disk rather than from what’s on the system where any 3rd party drivers would be configured.
Does this align with anyone else’s understanding of the new update process and if so does anyone know of a way to workaround it?
Is there a way to install our driver into the install disk so it loads when that disk is loaded? Is that what you meant Ben by “inject our driver to the
setup iso using dism”?
Yes, you are able to set the START of a mini-filter to boot time, I have
many that do just this. That said, I can’t imagine that MSFT does not
load ALL boot start drivers during this process. SYSTEM start? Sure,
they don’t have to be loaded. The reason being for data modification
filters. For this type of filter, or layered FS, they have to get them
into the stack otherwise no telling what could happen. If they bypass
boot start drivers, this is something very new and will break the
stability of the system, IMHO.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295
------ Original Message ------
From: xxxxx@digitalguardian.com
To: “Windows File Systems Devs Interest List”
Sent: 5/4/2016 11:06:32 AM
Subject: RE:[ntfsd] minifilter not loaded during some portion of Windows
10 update?
>My team’s research on this has shown the following scenario to be at
>play:
>
>Windows update in Win10 delivers minor updates much like Win 7/8, but
>also major updates which rev the version number of the OS and are
>applied in a new manner, such as the November update to version 1511 OS
>build 10586. These can be identified by the system going through 3
>phases, separated by reboots, of an ‘Updating Windows’ black screen:
>copying files, installing features and drivers, and configuring
>settings.
>
>The files for this type of update are staged in C:$Windows.~BT.
>Within that folder appears to be a Win10 install disk (files setup.exe,
>bootmgr, and others. folders boot, efi, sources, support and others).
>
>During the first phase, no Windows event logs are gathered and the
>driver for our product does not load. During the second phase, Windows
>event logs are gathered but our driver does not load. In the third
>phase event logs are gathered, and our driver is installed (again) and
>starts.
>
>The current theory is that in the first and possibly second phases the
>existing Windows 10 install is not booting at all, instead the system
>is booting off of the ‘install disk’ in $Windows.~BT
>
>If this is correct, then it would seem that no 3rd party drivers would
>load in those special phases because Windows is being loaded from that
>install disk rather than from what’s on the system where any 3rd party
>drivers would be configured.
>
>Does this align with anyone else’s understanding of the new update
>process and if so does anyone know of a way to workaround it?
>
>Is there a way to install our driver into the install disk so it loads
>when that disk is loaded? Is that what you meant Ben by “inject our
>driver to the
>setup iso using dism”?
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
Hi
Your description of the problem is correct. The initial phase of installation for these larger updates (November update and soon redstone) use this new environment. 3rd party drivers just simply aren’t there until later in the install. This is causing all sorts of problems with our product so I do feel your pain.
When talking to Microsoft about the problem they only seem to have answers for fairly tech savvy users who can download the iso from Microsoft and use the dism command line to mount the install.wim and inject drivers. This also includes loading the install.wim registry hives to crowbar the registry in.
All in all a shocking state of affairs.
Regards
Ben
Ben Lewis
DESlock Ltd
Sent from my iPhone
On 4 May 2016, at 18:07, “xxxxx@digitalguardian.com” wrote:
>
> My team’s research on this has shown the following scenario to be at play:
>
> Windows update in Win10 delivers minor updates much like Win 7/8, but also major updates which rev the version number of the OS and are applied in a new manner, such as the November update to version 1511 OS build 10586. These can be identified by the system going through 3 phases, separated by reboots, of an ‘Updating Windows’ black screen: copying files, installing features and drivers, and configuring settings.
>
> The files for this type of update are staged in C:$Windows.~BT. Within that folder appears to be a Win10 install disk (files setup.exe, bootmgr, and others. folders boot, efi, sources, support and others).
>
> During the first phase, no Windows event logs are gathered and the driver for our product does not load. During the second phase, Windows event logs are gathered but our driver does not load. In the third phase event logs are gathered, and our driver is installed (again) and starts.
>
> The current theory is that in the first and possibly second phases the existing Windows 10 install is not booting at all, instead the system is booting off of the ‘install disk’ in $Windows.~BT
>
> If this is correct, then it would seem that no 3rd party drivers would load in those special phases because Windows is being loaded from that install disk rather than from what’s on the system where any 3rd party drivers would be configured.
>
> Does this align with anyone else’s understanding of the new update process and if so does anyone know of a way to workaround it?
>
> Is there a way to install our driver into the install disk so it loads when that disk is loaded? Is that what you meant Ben by “inject our driver to the
> setup iso using dism”?
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:>
Thanks so much for confirming that. If you ever hear anything more from MS on other possible solutions I would hugely appreciate if that could be shared.
If it helps, I’ve determined that if the following three things all happen, it indicates that the phase of the update where 3rd party drivers are not loaded is about to begin. I’m going to use this to do a crude workaround.
- C:$WINDOWS.~BT\Sources\Setuphost.exe edits HKLM\BCD00000000\Objects{9dea862c-5cdd-4e70-acc1-f32b344d4795}\Elements\23000003\Element to be a GUID ({winsetupguid} in these steps).
- HKLM\BCD00000000\Objects{winsetupguid}\Elements\12000004\Element is “Windows Setup” without the quotes.
- HKLM\BCD00000000\Objects{winsetupguid}\Elements\32000004\Element is “$WINDOWS.~BT\Sources\SafeOS\boot.sdi” without the quotes.
You could definetly make your minifilter a boot start driver. Just make it to depend on FltMgr and you should be fine.
Gabriel Bercea
Windows Kernel Driver Consulting
www.kasardia.com
On Wed, May 4, 2016 at 3:24 PM -0700, wrote:
Thanks so much for confirming that. If you ever hear anything more from MS on other possible solutions I would hugely appreciate if that could be shared.
If it helps, I’ve determined that if the following three things all happen, it indicates that the phase of the update where 3rd party drivers are not loaded is about to begin. I’m going to use this to do a crude workaround.
1. C:$WINDOWS.~BT\Sources\Setuphost.exe edits HKLM\BCD00000000\Objects{9dea862c-5cdd-4e70-acc1-f32b344d4795}\Elements\23000003\Element to be a GUID ({winsetupguid} in these steps).
2. HKLM\BCD00000000\Objects{winsetupguid}\Elements\12000004\Element is “Windows Setup” without the quotes.
3. HKLM\BCD00000000\Objects{winsetupguid}\Elements\32000004\Element is “$WINDOWS.~BT\Sources\SafeOS\boot.sdi” without the quotes.
—
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at
To unsubscribe, visit the List Server section of OSR Online at
It doesn’t matter what you set your start-up type to be, 3rd party drivers are not loaded during the “safe os” phase of Windows setup.
Ben
Ben Lewis
Head of Software Development – Encryption Business Unit
DESlock Limited
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@kasardia.com
Sent: 05 May 2016 13:52
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Re[2]: minifilter not loaded during some portion of Windows 10 update?
You could definetly make your minifilter a boot start driver. Just make it to depend on FltMgr and you should be fine.
--------------------------------------------------------
Gabriel Bercea
Windows Kernel Driver Consulting
www.kasardia.comhttp:
On Wed, May 4, 2016 at 3:24 PM -0700, > wrote:
Thanks so much for confirming that. If you ever hear anything more from MS on other possible solutions I would hugely appreciate if that could be shared.
If it helps, I’ve determined that if the following three things all happen, it indicates that the phase of the update where 3rd party drivers are not loaded is about to begin. I’m going to use this to do a crude workaround.
1. C:$WINDOWS.~BT\Sources\Setuphost.exe edits HKLM\BCD00000000\Objects{9dea862c-5cdd-4e70-acc1-f32b344d4795}\Elements\23000003\Element to be a GUID ({winsetupguid} in these steps).
2. HKLM\BCD00000000\Objects{winsetupguid}\Elements\12000004\Element is “Windows Setup” without the quotes.
3. HKLM\BCD00000000\Objects{winsetupguid}\Elements\32000004\Element is “$WINDOWS.~BT\Sources\SafeOS\boot.sdi” without the quotes.
—
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at
To unsubscribe, visit the List Server section of OSR Online at
—
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>