C#でNTFSの代替データストリーム(Alternate Data Stream)を読み書きしたくなったので調べたことをメモ。正確な部分は把握しきれてないが、非公開関数であるNtQueryInformationFileで列挙するのが確実のようだ。

代替データストリームの取得（列挙）には以下の3つの方法がある。

1. BackupRead関数を使う
2. FindFirstStreamW関数, FindNextStreamW関数を使う (Windows Vista以降)
3. NtQueryInformationFile関数を使う (非公開関数)

正攻法は1, 2で、調べた限りADSの読み書きを行う既存のC#ライブラリは、1のBackupRead/BackupWriteを使っている。

ところがどう言う訳か、BackupReadでは列挙されないストリームが存在しうる。dir /rやNirSoft AlternateStreamViewでは表示されるにも関わらずだ。NTFSによるアクセス権限の問題らしいが、詳しいことは分からない。

NtQueryInformationFileはアクセス権限を無視して情報を取得できるらしく、前述のdirやAlternateStreamViewはこのAPIを使っているのだろう。多分。

2の方法は試してないが、アクセス権を無視するオプションはないらしいので望み薄と思われる。

こちらの記事のC#でNtQueryInformationFileを使ったサンプルで、無事目的のADSが取得できることを確認。というわけで、非公開関数ではあるもののNtQueryInformationFileを使うのが確実っぽい。

• NTFS代替データストリーム（ADS）一覧取得 | Memo+
• NTFS代替ストリーム | Netsphere Laboratories
• NTFS Alternate Streams: What, When, and How To
• Windows の謎を調べた - Neo's World
  • 登 大遊 - Windows のファイルのコピーは、驚くほど奥が深い。 | Facebook
• .NET Matters: Iterating NTFS Streams | Microsoft Docs
• Enumerating Alternate Data Streams - CodeProject
• A Win32-Based Technique for Finding and Hashing NTFS Alternate Data Streams

Proxmox VE 6.3のWindows 10ゲストでConnectX-3のSR-IOVが機能しないのは、PVE内蔵のmlx4ドライバが激古なのが原因のようだ。正確にはLinuxのインボックスドライバだが。

この状態だと、SR-IOVは有効でWindows側にVirtual Functionが生えているにもかかわらず、コード43となって、どうあがいてもデバイスが動かない。PVE側では以下のようなログが出る。

mlx4_core 0000:01:00.0: vhcr command:0x43 slave:1 failed with error:0, status -22
mlx4_core 0000:01:00.0: Received reset from slave:1

“Mellanox OFED for Linux Archived Bug Fixes”を眺めると、Internal Ref 1178129に、まさにそれっぽいバグが載っていた。

Description: Fixed an issue that prevented Windows virtual machines running over MLNX_OFED Linux hypervisors from operating ConnectX-3 IB ports.

When such failures occurred, the following message (or similar) appeared in the Linux HV message log when users attempted to start up a Windows VM running a ConnectX-3 VF:

“mlx4_core 0000:81:00.0: vhcr command 0x1a slave:1 in_param 0x793000 in_mod=0x210 op_mod=0x0 failed with error:0, status -22”

バグはIBポート、うちはEthポートという違いがあるが、状況としては極めて近い。この問題はMLNX_OFED v4.2-1.2.0.0で修正済みで、2021-02-10現在の最新版はv4.9-2.2.4.0 LTSであるから、とっくの昔に解決済みのハズである。

そんなバグに何で今更遭遇するの～？と思いきや、Linuxのインボックスドライバはなんとv4.0相当という事実が判明／(^o^)＼ Kernel.orgのBugzillaでも指摘されてるが、ガン無視の模様…。

しゃーないので自前ビルドしたら無事動いた。なんだよもう、めっちゃハマったやんけ！

それでも完全解決とはいかず、デバイスは動いているように見えるものの、なぜかパケットが流れない事がある。初期化系の何かっぽくて、何度かVMを再起動して一度通信できる状態になれば、途中で途絶する事はないのが不幸中の幸いではあるが。

もう1つ気になるのは「イーサネットの状態」のパケット数カウントが何かおかしいこと。受信パケットが常に0で、これが原因かわからんがVF経由だとiTunesでGracenoteへの接続に失敗する。virtio-netの方だと大丈夫なので、うちのネットワークがおかしい訳ではない。

SR-IOVまわりは情報があまりなくて、よう分からん。

(2021-12-07 追記)

WinOF v5.50.5400のKnown Issuesを眺めてたら、Internal Ref. 1297888にパケット数カウントがおかしい問題が思いっきり載っていた……というわけで、Windowsドライバのバグで確定。

回避策がN/Aなのでドライバ修正を待つしかないが、果たして更新されることはあるのだろうか。もうConnectX-3はLTSフェイズだしなぁ。ConnectX-4がお安く手に入ればいいんだけど。

Windowsの記憶域プール上にNTFSの仮想ボリュームを作る時は、NTFSのアロケーションユニットサイズ（クラスタサイズ）をよーく考える事。思わぬところでNTFSの最大容量制限に引っかかることになる。

NTFSでは1ボリュームあたりのクラスタ数は2^64-1個が上限となっている。つまり、ボリュームの最大容量はクラスタサイズで決まる（最大容量＝クラスタサイズ×最大クラスタ数）。アロケーションユニットサイズと最大容量の関係は下表となる。

2020-02-18現在、デフォルトクラスタサイズは昔から変わらず4KBのため、NTFSの1ボリューム≒1パーティションの最大サイズは16TBとなる。言うまでもないが、クラスタサイズを後から変更するのは無理。

一般的な使い方なら4KBでも十分だろうけど、容量拡張が容易な記憶域プールの場合、いとも簡単にこの最大ボリュームサイズ制限に引っかかってしまう。仮想ディスク上のNTFSボリュームを拡張すべく記憶域プールの容量を増やし、仮想ディスクを拡張し、いよいよNTFSパーティションを拡張だぜ！って段階で16TB制限に遭遇することとなり、マジ真顔状態となる。ありえねーよほんと……

16TBのHDDがふつーに変えてしまう昨今、やろうと思えばその辺のマザボですら16TB×8本で128TBの記憶域プールが作れてしまう。そう考えると、記憶域プール上のNTFSのクラスタサイズは64KB、と脳死対応をしてしまっていいのかも。あるいはNTFSを捨ててReFSに行ってしまうか。アロケーションユニットサイズは、ボリュームにおけるデータの最小管理単位なので、無暗に大きくすると無駄が多く発生する可能性もあって悩ましいところ。

あー、10TBのデータをバックアップから復元するのめんどくせー。

Windows 10 May 2019 Update（バージョン1903）において、Intel CPU内蔵GPUで動いているPCにリモートデスクトップ接続すると、リモデの画面が真っ黒になったりログインしています画面で固まったりする。WDDMドライバが何やら悪さしているらしく、グループポリシエディタでRDP時のWDDMグラフィックスドライバ使用を無効化すれば回避できるっぽい。

1. グループポリシーエディターを起動する（検索窓にgpeditと入れるのが手っ取り早い）
2. 以下のツリーたどり「リモートデスクトップ接続にWDDMグラフィックディスプレイドライバーを使用する」の設定を開く
   • コンピューターの構成
     • 管理用テンプレート
       • Windowsコンポーネント
         • リモートデスクトップサービス
           • リモートデスクトップセッションホスト
             • リモートセッション環境
   • 
3. 「無効」にチェックを入れOKを押す
4. Windowsを再起動する

公式には一部のIntel GPUでの問題とされているが、しょぼいGPU全般で起こるような気がするんですけど。自分が遭遇した限りでは、Intel GPU、VirtualBoxのVBoxVGA（アクセラレーションなし）、bhyveの各Windows環境で発生してるんですけど！

それどころか、言及されてるの見たことないけど、問題発生時は画面回りのみならずネットワーク周りも道連れに死んでる気がするんですけど！これも先の各環境で再現するんですけど！！超不便だし許さんぞMS……

Windows 10のシステムフォントを書き換えてNoto Sans CJKにしてるとVisual Studio 2013がインストール出来ないっぽい。

インストーラであるvs_community.exeを実行すると、画面中央に「Visual Studio」ロゴが表示された後、お馴染みの縦長インストーラUIが出るんだけれども、ただの真っ黒ウィンドウで1分程すると勝手に終了してしまう。

プロパティから「互換モードでこのプログラムを実行する」にチェックを入れて起動すると、画面は正しく出るものの今度は互換性エンジンが云々でインストールが出来ない。これは既知の問題というか、そういう仕様っぽいのである意味正常。

%TEMP%に作られるインストーラのログ（dd_vs_community_日付.logってファイル）を見たら
「[4F88:2824][2019-08-17T11:40:29]e000: MUX: ERROR: 'file:///C:/WINDOWS/FONTS/NotoSansCJKjp-Regular.otf' ファイルは、予測されるファイル形式の仕様に準拠していません。」
という怪しげな一文が…！当該箇所のログ全文は↓の通り。どう見てもフォントのインスタンスを作ってるっぽい所で落ちてる。

[4F88:2824][2019-08-17T11:40:29]e000: MUX:  ERROR: 'file:///C:/WINDOWS/FONTS/NotoSansCJKjp-Regular.otf' ファイルは、予測されるファイル形式の仕様に準拠していません。
[4F88:2824][2019-08-17T11:40:29]e000: MUX:  Stack:    場所 Adobe.CffRasterizer.OTFRasterizer.MapErrorCode(AdobeErrorCode error)
   場所 Adobe.CffRasterizer.OTFRasterizer.NewFont(UnmanagedMemoryStream fontFileStream, Uri sourceUri, Int32 faceIndex)
   場所 MS.Internal.FontFace.TrueTypeFontDriver.ReadCFFMetrics(FontFaceLayoutInfo cache, Boolean vmtxPresent, UInt16 typoAscent, UInt16 typoDescent)
   場所 MS.Internal.FontFace.TrueTypeFontDriver.ReadGlyfMetrics(FontFaceLayoutInfo cache, UInt16 indexToLocFormat, Boolean vmtxPresent, UInt16 typoAscent, UInt16 typoDescent)
   場所 MS.Internal.FontFace.TrueTypeFontDriver.ReadAdvances(FontFaceLayoutInfo cache, CheckedPointer hmtxTable, UInt16 numberOfMetrics, UInt16 indexToLocFormat, UInt16 typoAscent, UInt16 typoDescent)
   場所 MS.Internal.FontFace.TrueTypeFontDriver.GetLayoutFontFaceInfo(FontFaceLayoutInfo cache)
   場所 MS.Internal.FontCache.FontFaceLayoutInfo.MS.Internal.FontCache.IFontCacheElement.AddToCache(CheckedPointer newPointer, ElementCacher cacher)
   場所 MS.Internal.FontCache.HashTable.Lookup(IFontCacheElement e, Boolean add)
   場所 MS.Internal.FontCache.CacheManager.Lookup(IFontCacheElement e)
   場所 System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations, Boolean fromPublic)
   場所 MS.Internal.FontCache.CachedFontFace.CreateGlyphTypeface()
   場所 MS.Internal.FontFace.PhysicalFontFamily.GetGlyphTypeface(FontStyle style, FontWeight weight, FontStretch stretch)
   場所 MS.Internal.FontFace.PhysicalFontFamily.MS.Internal.FontFace.IFontFamily.GetTypefaceMetrics(FontStyle style, FontWeight weight, FontStretch stretch)
   場所 System.Windows.Media.Typeface.ConstructCachedTypeface()
   場所 System.Windows.Media.Typeface.get_CachedTypeface()
   場所 System.Windows.Media.Typeface.CheckFastPathNominalGlyphs(CharacterBufferRange charBufferRange, Double emSize, Double widthMax, Boolean keepAWord, Boolean numberSubstitution, CultureInfo cultureInfo, Int32& stringLengthFit)
   場所 MS.Internal.TextFormatting.SimpleRun.CreateSimpleTextRun(CharacterBufferRange charBufferRange, TextRun textRun, TextFormatterImp formatter, Int32 widthLeft, Boolean emergencyWrap)
   場所 MS.Internal.TextFormatting.SimpleRun.Create(FormatSettings settings, CharacterBufferRange charString, TextRun textRun, Int32 runLength, Int32 widthLeft)
   場所 MS.Internal.TextFormatting.SimpleRun.Create(FormatSettings settings, Int32 cp, Int32 cpFirst, Int32 widthLeft, Int32 widthMax)
   場所 MS.Internal.TextFormatting.SimpleTextLine.Create(FormatSettings settings, Int32 cpFirst, Int32 paragraphWidth)
   場所 MS.Internal.TextFormatting.TextFormatterImp.FormatLineInternal(TextSource textSource, Int32 firstCharIndex, Int32 lineLength, Double paragraphWidth, TextParagraphProperties paragraphProperties, TextLineBreak previousLineBreak, TextRunCache textRunCache)
   場所 MS.Internal.TextFormatting.TextFormatterImp.FormatLine(TextSource textSource, Int32 firstCharIndex, Double paragraphWidth, TextParagraphProperties paragraphProperties, TextLineBreak previousLineBreak, TextRunCache textRunCache)
   場所 System.Windows.Controls.TextBlock.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.StackPanel.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV)
   場所 System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV)
   場所 System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
   場所 System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Border.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Control.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Decorator.MeasureOverride(Size constraint)
   場所 System.Windows.Documents.AdornerDecorator.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   場所 System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   場所 System.Windows.UIElement.Measure(Size availableSize)
   場所 System.Windows.ContextLayoutManager.UpdateLayout()
   場所 System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
   場所 System.Windows.Media.MediaContext.InvokeOnRenderCallback.DoWork()
   場所 System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
   場所 System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
   場所 System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
   場所 System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   場所 System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   場所 System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   場所 System.Windows.Threading.DispatcherOperation.InvokeImpl()
   場所 System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
   場所 System.Threading.ExecutionContext.runTryCode(Object userData)
   場所 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   場所 System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   場所 System.Windows.Threading.DispatcherOperation.Invoke()
   場所 System.Windows.Threading.Dispatcher.ProcessQueue()
   場所 System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   場所 MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   場所 MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   場所 System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   場所 System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   場所 System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   場所 System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
   場所 System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
   場所 MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   場所 MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   場所 System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   場所 System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   場所 System.Windows.Threading.Dispatcher.Run()
   場所 Microsoft.Devdiv.Bootstrapper.ManagedUx.RunUI(ViewModelCommonUi viewModel)
   場所 Microsoft.Devdiv.Bootstrapper.ManagedUx.InternalRun()
   場所 Microsoft.Devdiv.Bootstrapper.ManagedUx.Run()
   場所 System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   場所 System.Threading.ThreadHelper.ThreadStart()

まさかと思ってシステムフォントを標準のYu Gothic UIに戻してみたら無事インストーラが立ち上がった。マジかよーって感じ。

確認してないけど、Notoの問題ってよりシステムフォントにOTF指定したのが不味いのかも？とりあえず無事インスコ出来てよかった。