GrowthUserVAを手動で設定することの危険性は何ですか？
私は32ビットシステムでVisual Studio 2010を実行しており、仮想メモリが不足するという問題に定期的に遭遇しているため、VSでのコピー/貼り付けなどはできなくなりました。
いくつかのオプションと Microsoft line をチェックアウトし、開いている拡張機能が少ない状態で実行されていることを示しました。それが機能しない場合は、bcedit/set GrowthUserVA 3072コマンドを使用します。
これで問題は軽減されたようですが、約1日使用した後、突然、Windowsでディスク容量が足りなくなったことがわかります。100GBを超えるドライブが利用可能です。たとえば、ファイルをコピーするスペースがないと言って、ファイルのコピーを停止します。ただし、「再試行」をクリックすると成功します。ディスクに書き込みを行っていた他の多くのプログラムは、定期的にフォールオーバーします。 （Skypeを含む... Skypeを常にディスクに書き込んでいる理由は？！）
私はchkdskを実行し、他の基本的なチェックを行ってから、構成の変更が原因であると結論付けました。幸い、デフォルトの設定に戻すことで問題が解決し、現在は問題なく活動しています。
GrowthUserVAに関するほとんどの記事（特にMicrosoftを除く）は、「自分の責任で使用してください」と言っています。しかし、この動作が発生した理由を誰かが説明できますか？Windows 7の構成に対する正当な変更と思われるもので何が問題になるのでしょうか？
記録としては、マシンは260Gb/5400rpmディスクドライブ、3.2Gb（有効）RAMを搭載したDell Vostroラップトップで、SP1より前のすべてのアップデートでWindows 7を実行していました。
Windowsは、32ビットシステムで利用可能な4GBのアドレススペースを半分に分割し、カーネルが2GBを取得し、プログラムが2GBを取得します（仮想化されているため、各プログラムは2GBを取得します）。 「bcedit/set GrowthUserVA 3072」コマンドは、各プログラムが3GBを取得し、カーネルスペースが1GBのみを取得するようにパーティションを変更します。ほとんどの場合これは問題なく機能しますが、気づいたように問題が発生する可能性があります。通常、カーネルスペースで実行される一部のドライバーは、2 GBのアドレススペースが利用可能であると想定してハードコーディングされており、2 GBのアドレススペースを使用しようとするときに問題が発生するかどうかを確認せずに問題を引き起こします。
大きなプロジェクトをコンパイルするために、時々GreaseUserVaを3gに設定しています。システムが休止状態に入ると、起動時にシステムが非常に不安定になることに気づきました。サーバーは通常、休止状態にならないと思います。
8 GBのRAM=でより大きなユーザーアドレススペースが必要な場合、最適な解決策はWindows 2003サーバーをインストールすることです。微調整は不要で、32ビットアプリはそれぞれ4 GBのアドレススペースを取得します。これが嫌いなドライバがいくつかあります。それがMSがデスクトップOSでこれを有効にしていない理由です。これをサポートしていないドライバの存在が原因のクラッシュは予測不可能であり、診断が難しく、ほとんどがサーバー環境で使用されます。
Vista/Win7カーネルを変更し、それをオプションとしてブートメニューに追加して、32ビットサーバーエディションで利用可能なメモリと同じメモリを取得することができます。
www.geoffchappell.com/notes/windows/license/memory.htm
これを行う既製のパッチがありますが、私はテストしていませんし、ソースもありません...