FIX 7.0移行でABHポーリングが失敗する原因とAccess Denied整理

本記事の対象となる事象は、Intellution FIX 7.0（Build 112）をWindows NTからWindows XPへ移行した後に、Allen-Bradley SLC 5/04をABHドライバでポーリングできなくなるケースです。Windows XPのアプリケーションログには「ABHSPOLL.EXE（siolib60.dll）Access is denied」といった記録が残り、外形上は稼働していてもデータ更新が止まる構図になります。事象の発生条件と切り分け軸を整理し、どの確認点が成立要件になりやすいかを説明します。 (Industrial Monitor Direct)

• 移行後に起きる症状とログの特徴
• ABHドライバとsiolib60.dllが通る経路
• 「Access is denied」が示す権限の不足点
• RSLinxとシリアル設定での切り分けポイント
• 対応の整理と再発防止の考え方

移行後に起きる症状とログの特徴

本記事で整理する論点の出発点は、「通信線やPLC側は正常に見えるのに、FIX側だけが読めない」という状態です。Industrial Monitor Directの事例では、Dellのマザーボードにあるネイティブのシリアルポートで接続し、RSLogix/RS Linx系の通信テストは成立している一方で、FIXのABH経由のポーリングだけが失敗しています。 (Industrial Monitor Direct)

このタイプは“物理層の断線”ではなく、OS上の実行権限やI/Oライブラリの実行条件が破綻している可能性が高いです。
そのため、現場では「ケーブル交換」「DF1設定の再投入」だけを繰り返しても改善しない構造になりやすく、Windowsのイベントログが判断材料として重要になります。ログ上は C:\FIX32\ABHSPOLL.EXE と C:\FIX32\siolib60.dll が名指しされ、Access is denied（アクセス拒否）が主語として出る点が特徴です。 (Industrial Monitor Direct)

つまり、障害点が「PLC」「RS-232」ではなく「ABHのポーリングプロセスがOS資源へ到達できない」側に寄るため、以降はOS差分と権限差分を軸に展開する必要があります。

ABHドライバとsiolib60.dllが通る経路

本記事の対象テーマを技術的に分解すると、ABHドライバはFIX内部のI/Oサーバとして動作し、シリアルI/Oの低レベル処理を siolib60.dll に依存する構成です。 (Industrial Monitor Direct)
この点から、OSが提供するCOMポート資源、割り込み処理、デバイスドライバ周辺の権限モデルが変わると、上位のFIX画面やデータベースが無事でも“読みに行く最下層”だけが止まる形になります。

移行で壊れるのは通信設定そのものではなく、ABHSPOLLが必要とする「低レベルI/Oの到達条件」です。
Windows NTとWindows XPの差分として、XPは標準ユーザーの権限がより限定され、プロセスがデバイスや特権操作へ触れる際の制約が強くなります、という整理がされています。 (Industrial Monitor Direct)
そのため、同じFIX32フォルダをコピーしても、実行ユーザーのトークン（権限の束）やファイルACL（アクセス制御リスト）が一致せず、結果としてDLLのロード、COM資源のオープン、共有メモリ周辺の操作が拒否される余地が生じます。

なお、同じ「読めない」でも、USB-シリアル変換器のタイミング問題やネットワーク遮断とは切り分け軸が異なります。ここを混同すると、原因系統が交差して調査が長引く形になりがちです。

「Access is denied」が示す権限の不足点

Windowsログ上のAccess is deniedは、単純なファイルの読み取り不可だけでなく、OS特権（ユーザー権利）の不足を含む場合があります。Industrial Monitor Directの整理では、ABHSPOLL.EXE側に対してフォルダ権限（C:\FIX32配下）を明示的に付けること、さらにローカルセキュリティポリシーで「Debug programs」「Load and unload device drivers」等の権利を付与することが挙げられています。 (Industrial Monitor Direct)

“Load and unload device drivers（デバイスドライバのロード/アンロード）”はカーネルモードへ触れる権利に近く、付与対象の扱いが実務上の確認点となります。 (Microsoft Learn)
同様に“Debug programs（プログラムのデバッグ）”はメモリ内容やカーネル/アプリ構造へ到達する余地を持ち、既定では管理者に限定されるという説明がされています。 (Microsoft Learn)
このため、XP移行後に「標準ユーザーでFIXを起動」「サービス実行アカウントが変更」「SIDsが変わり継承が崩れた」といった条件が重なると、ABHSPOLLだけが拒否される構図が成立します。

ただし、権限を広げれば必ず安全という整理にはなりません。特権付与はセキュリティリスクを増やし得るため、恒久運用に落とす前に、どの権利が成立要件だったのかを記録して縮退させる設計が必要になります（このあたりは後段で整理します）。

RSLinxとシリアル設定での切り分けポイント

本記事が示す状況では、RS Linxで通信テストが通ることが「物理接続の成立」を示しやすい一方で、FIXのABHが参照するAPIや実装が、XPとRS Linxの世代差で不整合になる余地があります。Industrial Monitor Direct側では、当該環境でRS Linx 6.12が言及され、XP互換としてRSLinx Classic 2.xx系への更新検討が挙げられています。 (Industrial Monitor Direct)
他方、Rockwell Automationの互換情報（サポート資料）では、RSLinx ClassicのリビジョンとWindowsの対応関係が論点として扱われており、特定版がXP SP3をサポートしない旨も示されています（閲覧にログインが必要な場合があります）。 (support.rockwellautomation.com)

RS Linxの動作確認と、FIX/ABHが前提とする“同一世代のコンポーネント”の整合は、原因系統を分ける上で重要です。
そのうえで、シリアルポート設定も残ります。XPではCOMポートのFIFOバッファ設定を変更でき、FIFOを無効化する手順が一般的なトラブルシュートとして説明されています。 (Parallax)
つまり、「権限が通ってもポーリングが不安定」という段階では、FIFO/割り込みやポートパラメータ差分が次の論点になります。

なお、本件がネイティブシリアルである場合でも、ボーレートやDF1フルデュプレックス等の整合は当然に前提となります。ただし、それらが成立しているのにAccess is deniedが出る点が、切り分け上の決定的な差になります。

対応の整理と再発防止の考え方

本記事の対象となる事象を「成立条件の不足」として整理すると、対応は大きく(1)実行権限とACL、(2)実行アカウントのユーザー権利、(3)周辺コンポーネント世代（RS Linx等）、(4)COMポート挙動の順で積み上げる形になります。Industrial Monitor Directでは、C:\FIX32への権限付与、ローカルセキュリティポリシーでの権利追加、管理者アカウントでの一時実行による確認、RS Linx更新、FIFO調整などが“解決策の束”として整理されています。 (Industrial Monitor Direct)

恒久対応は「権限を広げる」ではなく「ABHSPOLLが通る最小条件を同定して固定する」ことにあります。
そのため、実務では次のように“どこを触ったか”を残せる形式で整理されることが多いです（表はコピペで使える例です）。

さらにCOMポート設定については、OS側のパラメータを明示できる形で残すと、移設後の再現性が上がります。Industrial Monitor Directには MODE コマンド例も示されており、OS上の設定痕跡として使われます。 (Industrial Monitor Direct)

以上を踏まえると、再発防止は「ファイルコピーで移行しない」「OS/ドライバ/周辺ツールの世代を揃える」「権限付与は最小化して固定する」に収束します。なお、どうしても環境固定が必要な場合、旧NT環境を仮想マシン（VMware等）として保持する回避策も提示されていますが、これは同一環境を温存する設計に分類されます。 (Industrial Monitor Direct)
そのため、最終的には“現物環境で成立していた条件を、XP上で同じ順序で再構築する”ことが中心になり、途中で権限を広げた箇所は、あとで縮小できるように記録しておく必よ うがあります。