Windows 11 を 24H2 に更新したら、長年愛用してきた MarkdownPad 2 が突然起動しなくなった――そんな報告が世界中で出ています。本記事では、この現象の原因と考えられる OS 側の仕様変更、そして実用的な回避策や代替エディタ選びのポイントを、技術的な背景も含めて整理します。
Windows 11 24H2 更新後に MarkdownPad 2 が起動しない現象
まずは、実際に報告されている症状を整理します。
- Windows 11 を 24H2 に更新する前は、MarkdownPad 2 は問題なく起動していた。
- 24H2 を適用した直後から、MarkdownPad 2 を起動すると即座に例外が発生してアプリが落ちる。
- イベントログやクラッシュダイアログを見ると、代表的には次のような例外が表示される：
System.Windows.Markup.XamlParseException
-> System.InvalidCastException: Specified cast is not valid.
at Microsoft.ClearScript.Windows.ActiveScriptWrapper32..ctor(...)
at Microsoft.ClearScript.Windows.JScriptEngine..ctor(...)
at MarkdownPad2.Markdown.GitHubFlavoredMarkdownOffline..ctor()
at MarkdownPad2.UserControls.MarkdownEditor..ctor()
Microsoft Q&A でも、Windows 11 環境で MarkdownPad 2 が XamlParseException と InvalidCastException を伴って起動時に落ちる事例が報告されており、質問者・回答者ともに Windows Update 適用後から再現し始めたと述べています。
同スレッドでは、別のユーザーが詳細な検証の結果として、「24H2 を適用すると必ず再現し、24H2 未適用の環境では再現しない」と報告しており、この回答は質問者によって「解決」としてマークされています。
| 項目 | 内容 | 補足 |
|---|---|---|
| 発生タイミング | Windows 11 を 24H2 に更新した直後 | それ以前のバージョンでは正常動作 |
| エラー種別 | XamlParseException 内部で InvalidCastException | WPF コントロール（MarkdownEditor）のコンストラクタ内で異常終了 |
| スタックトレース | Microsoft.ClearScript.Windows.ActiveScriptWrapper32 / Windows.JScriptEngine で失敗 | JScript の COM ホスト初期化に失敗していると読める |
| 再現条件 | MarkdownPad 2 を起動するだけで即クラッシュ | 設定削除や再インストールでも改善しない報告が多い |
原因の整理：Windows 11 24H2 とレガシー JScript 実行環境の変更
スタックトレースから読み取れること
先ほどのスタックトレースを見ると、問題の発火点は MarkdownPad 2 が持つ GitHubFlavoredMarkdownOffline クラスのコンストラクタであり、内部で ClearScript というライブラリを通じて Microsoft.ClearScript.Windows.JScriptEngine を初期化しようとして失敗していることが分かります。
- ClearScript は .NET アプリケーションから JavaScript（JScript/VBScript や V8）をホストするためのライブラリ。
- MarkdownPad 2 は、この ClearScript の JScript エンジンを使って、オフラインの GitHub Flavored Markdown（GFM）処理を行っていると考えられる。
- エラーは
ActiveScriptWrapper32→WindowsScriptEngine→JScriptEngineという COM ラッパー初期化の途中でInvalidCastExceptionが発生している。
つまり、「JScript を COM 経由でホストしている部分」で、Windows 11 24H2 以降の変更と何らかの不整合が発生している可能性が高い、という読みができます。
Windows 11 24H2 で JScript エンジンが JScript9Legacy に変更
Windows 11 24H2 では、セキュリティ強化の一環として、長年使われてきた古い JScript.dll ベースのエンジンから、JScript9Legacy.dll という新しいスクリプトエンジンに切り替える方針が Microsoft から公式にアナウンスされています。
- 24H2 以降、JScript を利用するすべてのスクリプト処理は、既定で JScript9Legacy にリダイレクトされる。
- JScript9Legacy は JScript9 をベースにした「より安全な」エンジンであり、従来の JScript で問題だった脆弱性を軽減する目的で導入された。
- この変更は Windows 11 24H2 以降のみに影響し、それ以前のバージョンには適用されない。
ところが、この切り替えにより、JScript を COM 経由でホストしている古いアプリケーションが相次いで動作不良を起こしていることが、各種ベンダーブログやフォーラムから報告されています。
- ビルドツールの FinalBuilder / Automise は、24H2 への更新後に JScript ベースのスクリプトが動作しなくなったと報告し、原因を「24H2 で JScript.dll が JScript9Legacy.dll をロードするポリシーが既定有効になったこと」と分析しています。
- POS ソフトウェア SambaPOS でも、Windows 11 24H2 への更新後に ClearScript の JScriptEngine 初期化で同様のエラーが発生しており、JScript9Legacy への切り替えが原因とみられるケースが共有されています。
つまり、MarkdownPad 2 だけが特別というより、「古い .NET ＋ ClearScript ＋ JScript COM ホスト」構成のアプリが 24H2 でまとめて影響を受けている、という構図になっています。
MarkdownPad 2 側の事情：最終リリースは 2014 年
MarkdownPad 2 自体も、残念ながらかなり古いソフトです。
- 公式サイトのニュースによれば、MarkdownPad 2.5 のリリース日は 2014 年 12 月 24 日で、それ以降大きなメジャーアップデートは公開されていません。
- 2.4 なども含め、更新履歴はすべて 2014 年までで止まっています。
- 公式サイト自体は現在も「Windows 向け Markdown エディタ」として案内がありますが、最新 OS への対応状況や 24H2 対応に関するアナウンスは特に見当たりません。
つまり、「Windows 側の仕様変更（JScript9Legacy への切り替え）」と「アプリ側が 10 年以上アップデートされていない」という 2 つの要因が重なり、今回の互換性問題が露呈した、と考えるのが自然です。
| 観点 | 現状 | 影響 |
|---|---|---|
| OS 側（Windows 11 24H2） | JScript9Legacy を既定有効化し、古い JScript.dll を置き換え | COM 経由で JScript を使うレガシーアプリに互換性問題が出やすい |
| アプリ側（MarkdownPad 2） | .NET 4 系＋古い ClearScript を使用、2014 年以降アップデート無し | 新しい JScript9Legacy との組み合わせでテストされておらず、例外発生 |
| 開発体制 | 個人開発に近い単独開発者・アップデート停止 | 24H2 対応版への更新は現実的に期待しにくい |
結論：原因は 24H2 の変更が濃厚、根本解決にはアプリ更新が必要
以上を踏まえると、質問の核心である「原因は Windows 更新か？」については、次のように整理できます。
- 24H2 未適用の Windows 11 では MarkdownPad 2 は正常動作し、24H2 適用直後にのみ起動エラーが発生するという検証結果がある。
- 24H2 では JScript 実行エンジンを JScript9Legacy へ切り替える仕様変更があり、他の JScript/COM 依存アプリでも同種の障害が報告されている。
- MarkdownPad 2 は古い ClearScript を使って JScript をホストしており、2014 年以降アップデートされていない。
このため、「原因はほぼ間違いなく Windows 11 24H2 の仕様変更側にあるが、アプリ側が古くアップデートされていないことがトリガーになっている」と考えるのが妥当です。
そして根本的な意味での「修復」は、MarkdownPad 2 を新しい .NET／ClearScript／JScript9Legacy 環境向けにソースレベルで更新し、再ビルドすることがほぼ唯一の道になります。しかし、開発が事実上止まっている現状では、公式の修正版リリースを待つのは現実的ではありません。
そのため、実用的な選択肢としては次の優先順位になります。
- 別の Markdown エディタへ乗り換える（最も推奨）
- MarkdownPad 1 を暫定的に使う（機能は落ちるが 24H2 でも動くという報告あり）
- どうしても MarkdownPad 2 が必要なら、互換モードや設定変更、仮想マシンなどで「囲い込んで」使う
以降では、これらの現実的な回避策を具体的に解説していきます。
回避策 1：別の Markdown エディタに乗り換える（最優先）
仕事や継続的な執筆で Markdown を使うのであれば、積極的にエディタを乗り換えるのがもっとも安全で、将来の OS 更新にも強い選択です。
おすすめ代替エディタの候補
| エディタ | 料金・ライセンス | 主な特徴 | 向いている用途 |
|---|---|---|---|
| Visual Studio Code + Markdown Preview Enhanced | 本体・拡張とも無料 | 拡張機能で GFM、MathJax、Mermaid、PlantUML、PDF 出力など高機能なプレビューに対応。 | 技術文書、ドキュメント、ブログ執筆、プログラマ向け |
| Typora | 買い切りライセンス（1 回払い） | プレーンな見た目で WYSIWYG に近い編集体験。Markdown 記号を極力隠し、集中して書ける UI。 | 長文執筆、論文、レポート、スタイルにこだわりたい個人 |
| Obsidian | 基本利用は無料（個人・商用とも無料プランあり） | ノート間リンクとグラフビューが強力な「第二の脳」系エディタ。プラグインも豊富。 | ナレッジ管理、Zettelkasten、技術メモ、研究ノート |
| MarkText | MIT ライセンスのオープンソースで無料 | シンプルな UI とリアルタイムプレビュー。CommonMark / GFM / 一部 Pandoc 拡張に対応。 | 軽量で綺麗な Markdown 専用エディタが欲しい人 |
| Notepad++ + Markdown プラグイン | 無料 | テキストエディタとしての定番。プラグインで Markdown ハイライトやプレビューを追加可能。 | 既に Notepad++ に慣れているユーザー |
| Windows 11 の新しいメモ帳（Notepad） | Windows 11 に同梱 | 24H2/25H2 世代では Markdown 形式のテキスト装飾／プレビューに対応しつつあり、簡易な Markdown 編集が可能。 | 軽いメモや README 程度の Markdown 編集 |
MarkdownPad 2 からの乗り換え手順（一般的な流れ）
どのエディタを選ぶにしても、既存の .md ファイルは基本的にそのまま利用できます。典型的な乗り換えの流れは次のとおりです。
- Markdown ファイルの保存場所を整理
プロジェクト単位・クライアント単位など、自分が管理しやすい単位でフォルダを整理しておきます。 - 候補エディタをインストール
VS Code や Obsidian など、1〜2 個に絞って実際に触ってみるのが手っ取り早いです。 - テーマ・フォントを MarkdownPad 2 に近づける
ダーク／ライトテーマや等幅フォントを変更して、視認性を MarkdownPad 2 に近い感覚に調整します。 - ショートカットの再学習
VS Code ならCtrl+Bで太字、Ctrl+Shift+Vでプレビュー表示など、MarkdownPad 2 時代に多用していた操作を中心に覚え直します。 - テンプレートやスニペットを作る
よく使う記事構造（見出しや定型文）をスニペット化すると、MarkdownPad 2 より快適になることが多いです。
Windows 11 の更新は今後も続くため、長期的には「今後もメンテナンスされるエディタ」に乗り換えるのが最もコストが低い、というのが現実的な結論です。
回避策 2：MarkdownPad 1 を暫定利用する
Microsoft Q&A では、MarkdownPad 1 は 24H2 適用後も起動できているとの報告があります。
MarkdownPad 1 は、2 に比べて機能は控えめですが、次のようなケースでは十分実用的です。
- シンプルな Markdown（GFM の拡張をあまり使わない）しか書かない。
- 複数タブでの同時編集や高度なプレビュー機能がなくても困らない。
- 一時的な避難先として「とりあえず MarkdownPad の雰囲気で書きたい」。
| 機能 | MarkdownPad 1 | MarkdownPad 2 |
|---|---|---|
| GitHub Flavored Markdown (GFM) | 非対応 or 限定的 | オフライン GFM エンジンに対応（今回の不具合の原因領域） |
| 複数タブ編集 | 弱い／無し | 複数タブを前提にした UI |
| プレビューエンジン | 比較的シンプル | Awesomium + ClearScript など複数コンポーネントに依存 |
| 開発状況 | 既に凍結済み | 2 と同様に 2014 年以降更新なし |
長期的な解ではありませんが、「どうしても MarkdownPad ライクな UI が必要」「すぐには新エディタに慣れない」という場合の ワンクッションとしての選択肢としてはアリです。
回避策 3：どうしても MarkdownPad 2 を使いたい場合の一時しのぎ
業務上の理由などでどうしても MarkdownPad 2 を維持したい場合には、以下のような「囲い込み」的な対処が考えられます。ただし、いずれも自己責任であり、将来の Windows 更新で再び壊れる可能性がある点に注意してください。
互換モードでの起動を試す
まず試しやすいのが、互換モードでの実行です。
- MarkdownPad 2 のショートカットまたは
MarkdownPad2.exeを右クリックして「プロパティ」を開く。 - 「互換性」タブを開き、「互換モードでこのプログラムを実行する」にチェックを入れる。
- ドロップダウンから「Windows 7」や「Windows 8」など、比較的古いバージョンを選ぶ。
- 必要に応じて「管理者としてこのプログラムを実行する」にもチェックし、「OK」で閉じる。
- ショートカットから MarkdownPad 2 を起動し、挙動が変わるか確認する。
互換モードは OS 側が一部の API 振る舞いをエミュレーションする仕組みですが、今回のような JScript エンジンレベルの変更までは覆してくれない可能性が高く、「効いたらラッキー」程度と考えるのがよいでしょう。
設定ファイル（user.config）で Markdown 処理エンジンを切り替える
前述の通り、エラーの起点は オフライン版 GitHub Flavored Markdown エンジンとみられます。そこで、設定ファイルから「GitHubFlavoredMarkdownOffline」系のエンジン指定を別のものに変えてみる、というアプローチがあります。
設定ファイルの場所を探す
MarkdownPad 2 は ClickOnce アプリとして配布されており、設定はユーザーの AppData 配下の user.config に保存されています。別のブログでも、次のようなパスの例が紹介されています。
C:\Users\ユーザー名\AppData\Local\MarkdownPad2\
MarkdownPad2.exe_Url_xxx\2.4.4.40074\user.config
バージョン番号や Url_xxx の部分は環境によって異なるため、確実に見つけたい場合は以下のような手順が有効です。
%LOCALAPPDATA%\MarkdownPad2配下をエクスプローラーで開き、user.configを検索する。- PowerShell を使う場合は、ブログで紹介されているように
Apps\2.0配下からuser.configを再帰検索し、「MarkdownPad」という文字列を含むものを探す。
バックアップを必ず取る
編集前に user.config を別の場所へコピーし、必ずバックアップを作成してください。内容は XML 形式で、人間が直接編集できるものですが、誤って壊すと MarkdownPad 2 が起動しなくなったり、設定が初期化されるリスクがあります。
Markdown 処理エンジンの設定を確認・変更する
設定ファイルには、次のような <setting> 要素が並んでいます。たとえば、あるブログでは Markdown 拡張モードを有効にするために、次のような設定を追加する例が紹介されています。
<setting name="Markdown_MarkdownProcessor" serializeAs="String">
<value>MarkdownExtraMode</value>
</setting>
環境によってキー名や値は異なりますが、以下のような方針で編集を試せます。
- 「GitHub」や「GitHubFlavoredMarkdownOffline」といった文字列を検索し、Markdown 処理エンジンに関連する設定を探す。
- その値を、よりシンプルなエンジン（例：
MarkdownやMarkdownExtraModeなど）に変更して保存する。 - MarkdownPad 2 を起動し、例外が変化するか（あるいは起動するか）確認する。
この方法で「危険な」GitHub オフラインエンジンを避けられれば、起動だけはできる可能性があります。ただし、
- どの値にすれば確実に安全、という保証はない。
- 将来の Windows 更新で再び動かなくなる可能性は残る。
といった前提があるため、あくまで「必要なデータを急ぎ取り出したい」「どうしても一時的に MarkdownPad 2 を動かしたい」といった場面で限定的に使うのがよいでしょう。
仮想マシン上に 24H2 未適用の Windows を用意して使う
より保守的なアプローチとして、MarkdownPad 2 専用の仮想マシン（VM）を用意する方法があります。
- ホスト OS（メインの Windows 11 24H2）はそのまま最新状態で維持する。
- Hyper-V や VMware、VirtualBox などで Windows 10 または 24H2 未満の Windows 11 をインストールした VM を作成する。
- その VM 内に MarkdownPad 2 をインストールし、そこだけで MarkdownPad 2 を使う。
- セキュリティとライセンスの観点から、VM のネットワーク接続や Windows ライセンス条件を必ず確認する。
この方法は一見手間ですが、
- メイン環境のセキュリティパッチは最新のまま維持できる。
- VM 側は「MarkdownPad 2 が動く状態」に固定してしまえる。
というメリットがあり、「レガシーアプリを囲い込む」一般的なパターンとして、企業環境でもよく採用されるやり方です。
レジストリで JScript の挙動を変える方法について（上級者向けの注意事項）
一部のアプリケーション（FinalBuilder や SambaPOS など）では、Windows 11 24H2 で導入された JScript9Legacy エンジンをレジストリポリシーで「古いエンジンに戻す」ワークアラウンドが紹介されています。具体的には、JScriptReplacement というレジストリ値を追加・変更して挙動を切り替える手法です。
しかし、Microsoft は公式ブログで「互換性問題がある場合はサポートに相談し、必要に応じて JScript にロールバックする」と述べており、一般ユーザーに対してレジストリを直接編集する方法は案内していません。
レジストリ編集は OS 全体のセキュリティ挙動を変える行為であり、誤設定のリスクも高いため、本記事では具体的な値や手順はあえて詳述しません。どうしてもこの方向での回避を検討する場合は、
- 企業の IT 管理者や専門家と相談する。
- 変更前にシステム全体のバックアップを取得しておく。
- アプリ側の恒久対応（別エディタへの移行など）を並行して進める。
といった点を必ず守ることを強くおすすめします。
やってはいけない／避けたい対応
短期的には効果がありそうに見えても、長期的なリスクが大きい対応もあります。
- Windows 11 24H2 からのロールバックを安易に行う
更新のアンインストールや復元ポイントからのロールバックは、他のアプリやドライバへの影響・セキュリティパッチの欠落など、リスクが大きいです。Microsoft Q&A でも、回答者はダウングレードを推奨していません。 - ネット上の「非公式パッチ」やクラック版を導入する
出どころが不明な EXE／DLL の差し替えは、マルウェアの温床になりがちです。 - セキュリティ機能（ウイルス対策、SmartScreen 等）を無効化する
一見症状が改善するように見えても、本質的な解決ではなく、むしろリスクだけが増大します。
「MarkdownPad 2 を動かすために、OS 全体の安全性を犠牲にする」ような選択肢は、避けるべきです。
技術的背景をもう少し深掘りしてみる
COM ベース JScript ホストと ClearScript の関係
ClearScript は .NET アプリケーションに JScript/VBScript や V8 ベースの JavaScript を組み込むためのライブラリであり、Windows 上では JScript.dll を COM 経由で呼び出してスクリプトを実行するモードをサポートしています。
MarkdownPad 2 のスタックトレースでは、
ActiveScriptWrapper32がJScriptの COM オブジェクトを生成しようとするWindowsScriptEngine→JScriptEngineとラップされていく途中でInvalidCastExceptionが発生する- 結果として
GitHubFlavoredMarkdownOfflineのコンストラクタが例外を投げ、WPF コントロールの構築が失敗する
という流れが見て取れます。
JScript9Legacy 導入による互換性問題
JScript9Legacy は、Internet Explorer 時代の JScript よりも安全でモダンな実行エンジンですが、COM レベルでのインターフェースや動作が完全に後方互換とは限らず、Windows IT Pro ブログのコメント欄でも Classic ASP などの古いアプリケーションが一斉に壊れたという指摘がなされています。
FinalBuilder のブログも、24H2 で JScript.dll が JScript9Legacy.dll をロードするようになることで、既存のスクリプトが動作しなくなったと説明しており、同じ種類の波及障害が各所で起きていることが分かります。
MarkdownPad 2 もまた、「古い JScript を前提に作られた .NET アプリ」であるため、この変更の影響を免れなかったと考えられます。
まずやることチェックリスト
ここまでを踏まえて、「とりあえずどこから手を付ければよいか」をチェックリスト形式でまとめます。
- OS バージョンを確認する
設定 > システム > バージョン情報あるいはwinverコマンドで、Windows 11 のバージョンが 24H2 かどうかを確認。- 24H2 であれば、本記事で説明している現象に該当する可能性が高いです。
- Markdown ファイルと設定ファイルのバックアップ
.mdファイルをすべてバックアップ（クラウドでも外付けでも可）。%LOCALAPPDATA%\MarkdownPad2以下のuser.configなども一緒にコピーしておく。
- 別エディタの検証
- VS Code / Typora / Obsidian / MarkText などから 1〜2 個を選び、実際に 1〜2 本のドキュメントを移行してみる。
- 「GFM が必要か」「数式や図をどれくらい使うか」を考慮して選ぶ。
- MarkdownPad 1 の利用可否を検討
- シンプルな用途なら MarkdownPad 1 でも十分なケースが多い。
- GFM の高度な機能が必要なら、早めに別エディタへの移行を進める。
- どうしても必要な場合のみ MarkdownPad 2 の延命策を試す
- 互換モードでの起動。
user.configでの Markdown エンジン変更（バックアップ前提）。- 仮想マシン内での利用。
| 優先度 | 対応 | コメント |
|---|---|---|
| 高 | データと設定のバックアップ | いつ何をしても後悔しないための保険。まず最初にやるべき。 |
| 高 | 代替エディタの選定・試用 | 長期的な解決策。将来の OS 更新にも強い。 |
| 中 | MarkdownPad 1 の暫定利用 | 妥協案としては悪くないが、根本解決ではない。 |
| 低 | MarkdownPad 2 延命（設定編集・VM 等） | どうしても必要な場合の最終手段。手間とリスクを理解した上で実施。 |
今後の見通しと戦略
Windows 11 24H2 以降、JScript9Legacy が既定になったことは、単に MarkdownPad 2 だけの問題ではなく、Windows 全体として「古いスクリプト環境を段階的に廃止していく」流れの一部と考えられます。
一方で、ユーザー側の選択肢としては、
- Windows 標準のメモ帳では Markdown 対応が進み、軽い用途なら OS 標準機能で完結できる方向に進んでいる。
- VS Code や Obsidian、Typora、MarkText など、モダンな Markdown エディタは今も活発に開発されている。
という状況です。つまり、
- OS 側はレガシー環境を切ってセキュリティ／モダン化へ進む
- アプリ側はその上で動く新世代エディタへと置き換えていく
という「世代交代」が起きている、と捉えると分かりやすいかもしれません。
MarkdownPad 2 は、Windows 上で本格的な Markdown 編集を普及させた立役者でしたが、24H2 以降の世界では、レガシーアプリとして静かに引退させるタイミングに来ているとも言えます。
ひとことでまとめると――
- はい、原因は Windows 11 24H2 の更新でほぼ間違いありません。
- 実用的な解決策は、MarkdownPad 1 か別の Markdown エディタへ切り替えることです。
- MarkdownPad 2 の「ネイティブ復旧」は、開発が再開されない限り非常に難しい見込みです。
いまのうちに新しいエディタへ移行しておけば、今後の OS 更新や PC 買い替え時にも悩まされずに済みます。この機会に、自分のワークフローに合った「次の相棒」を探してみるのがおすすめです。
コメント