80 likes | 225 Views
File System and File System Filter Ecosystem Update. Neal Christiansen Development Lead File System Filter Team. BOOT.INI and Longhorn. The boot.ini file is no longer used to configure boot parameters. New BCD (boot configuration data) file Implemented as a registry hive
E N D
File System and File System Filter Ecosystem Update Neal Christiansen Development Lead File System Filter Team
BOOT.INI and Longhorn • The boot.ini file is no longer used to configure boot parameters. • New BCD (boot configuration data) file • Implemented as a registry hive • Resides in \boot\bcd • There is a new tool called bcdedit which is used to configure options • Boot.ini is still used for downlevel operating systems if you are booting multiple OS’s on the same system
Useful bcdedit commands • bcdedit –enum • List current settings • bcdedit –enum all • List all settings • bcdedit /? • Basic help • bcdedit /? Types • Lists the bulk of the settings
Useful bcdedit commands • Enable debugging • bcdedit -debug on • Followed by one of the following: • bcdedit -dbgsettings serial debugport:1 baudrate:115200 • bcdedit -dbgsettings 1394 CHANNEL:32 • bcdedit –dbgsettings USB TARGETNAME=U1
Doing IO from Completion Routines • Many of you issue IO operations from IO Completion routines (or post-operation callbacks) when those routines are at an IRQL level lower then DPC level • Filter manager promoted this with routines like FltDoCompletionProcessingWhenSafe
Doing IO from Completion Routines • We have determined that it is not safe to ever perform any operation in a completion (or post-operation) callback routine regardless of your current IRQL level • We have been seeing deadlock with various storage drivers because of this • The most common scenario we have seen is when using dynamic disks with RAID enabled • We have seen it with other drivers as well • Consider this a new “rule for filters”
Doing IO from Completion Routines • It is our very strong recommendation that you modify your existing products across all OS’s to stop doing this • You have two options: • If the operation is synchronous you should synchronize back to your dispatch routine • Use IoIsOperationSynchronous • If the operation is asynchronous you should queue the request to a worker thread • You may have to throttle your worker thread usage because you can cause deadlocks if you consume all of the worker threads
Doing IO from Completion Routines • What is filter manager going to do about this? • FltDoCompletionProcessingWhenSafe will be modified to either queue the request or automatically synchronize and call the specified routine. • This will happen automatically so if you use the current routine you should not have to change anything • We are going to modify the minifilter verifier to detect this situation and break