Windowshardがハング/フリーズした場合の機器の動作をテストする必要があります(例:フリーズした画面、LEDの点滅、入力に対する反応がない、Ctrl + Alt + Delなど)。かなり短期間で十分な実験を行うために、私はこれらのハングをプログラム的またはその他の方法で開始する必要があります。
私は特にWindows 10に興味がありますが、他のバージョンのためのどんな作業方法でも評価されます。
私がこのトピックに対して行ったすべての検索は、驚くことではありませんが、これらの状況を排除する方法についての議論に私をもたらします。それで問題は十分に奇妙に思えるかもしれません。
フィードバック:答えやコメントで提供されているrecipesをたくさん試してみました。まず第一に、私はBSoDをもたらすクラッシュには興味がありませんでした(それが私がクラッシュではなくフリーズを説明した理由です)。
私は、Windows 10 64-bitが多くの方法に対して優れた耐性を示したことを認めなければなりません。ほとんどすべてのCPUロードメソッド(fork-bomb、ループなどを含む)に非常によく対応します。即時エラーを発生させるメソッド(ほとんどのNotMyFaultハングメソッド)は、再起動またはシャットダウンでOSによって処理されます(これは私が追求したものではありません)。 NotMyFaultのメモリリークメソッドによって最良の結果が達成されました - リブートの可能性なしで本当のフリーズ。
最後に、私は、Windowsをフリーズさせることについて語っているマイクロソフトによる大量の文書に感銘を受けました。彼らはこの部分を反対よりもずっとよく知っているように見えます(凍結との戦い);-)
USBキーボードでは、レジストリでキーボードによるクラッシュを有効にする必要があります。レジストリキーHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\ParametersにCrashOnCtrlScrollという名前の値を作成し、0x01のREG_DWORD値に等しく設定します。
これらの設定を有効にするには、システムを再起動する必要があります。
これが完了したら、次のホットキーシーケンスを使用してキーボードクラッシュを開始することができます。一番右のCTRLキーを押しながらSCROLL LOCKキーを2回押します。
またはフォーク爆弾を起動することもできます: これを参照してくださいSO question
NotMyFault もあります。
Notmyfaultは、クラッシュ、ハング、およびWindowsシステムでのカーネルメモリリークを引き起こすために使用できるツールです。デバイスドライバやハードウェアの問題を特定して診断する方法を学ぶのに役立ちます。また、不正な動作をするシステムでブルースクリーンダンプファイルを生成するのにも使用できます。
OSが反応しなくなったときの外部デバイスの反応をテストしているようです。
ハードウェアを仮想化されたWindowsインストールに接続できる場合は、仮想マシンを何度でも一時停止して再開できます。 VirtualBox(またはその他のデスクトップ仮想化)環境に目的のOSをインストールし、使用されているハードウェアインターフェイス(USB、Ethernet、その他)をVMに公開します。
その後、仮想マシンを 一時停止および再開 することができます。
少なくとも数年前の古いWindowsバージョンでは、次のように動作しました。
私は無限ループでCプログラムを書きました:
while(1) {}
...それから私はタスクマネージャでそのプログラムに「リアルタイム優先」を与えました(これを行うことができるAPIもあります)。
マルチコアシステムでは、各コアで1つのループが実行されるように、これを複数回実行する必要があります。
最も強いカーネルハング(すなわち、マウス追跡がないなど)は、コードが割り込みをオフにした状態でカーネルモードで無限ループに入るときである。
デバイスドライバでこれを達成することは可能です、そしてさらに良いことに、あなたはそれがあなたのコントロールの下でハングを始めそして止めるようにドライバを書くことができます(無限ループがあなたがコントロールしている状態をテストしていると仮定します)。
このドライバをどのように書いてインストールするかは、別の質問または3つのトピックの話題になりますが、それが私が採用するアプローチです。
StackOverflowで次の質問を確認してください。 ウィンドウを短期間フリーズさせる方法
それのtl; drは(確実に)それをする方法がないということです。
Windowsをフリーズさせたりハングさせたりするのではなく、単にあなたの機器との通信を中断することができます。
私はあなたの機器が何であるかそしてあなたがそれをどのように接続するのか見当がつかない。 USBまたはイーサネットアダプタの場合、たとえば、デバイスマネージャで簡単に無効にしたり、取り外したりできますか。システムを強制的にクラッシュさせたりハングアップさせたりすると、さまざまな方法でシステムに損傷を与える可能性があるので、注意してください。
カーネルデバッグモードはオプションではありませんか?
私はそれをWindows 7でセットアップしました、そしてこの答えのリンクされた指示はXPまたはそれ以降を指定します、それでそれはWindows 10で動作するはずです。
私は、 FireWire/1394 の上に設定しました。しかし、あなたは ネットワーク上でそれを行うこともできます または USB (そして more )。
基本的に、
昇格されたプロンプトでこれらのコマンドを実行してターゲットコンピュータを設定します(チャンネルn
を選択)。
bcdedit /debug on
bcdedit /dbgsettings 1394 channel:n
これはmsconfig
のブートタブに行き、 'Advanced'ボタンを選択するのと同じです。
次に(ターゲットコンピュータを再起動した後)、ターゲットコンピュータのWinDbgと同じビット数を使用して、ホストコンピュータでWinDbgを実行します。
ホストコンピュータからいつでもカーネルの実行を一時停止するだけです。あなたがテスト機器がそれが走っているという何らかの非同期操作を持っているならば、これは他の手段と同じくらい効果的であるべきです。
マウスカーソルがまだ画面上を移動するため、これが完全フリーズに該当するかどうかはわかりませんが、デバイスI/Oエラー、具体的にはハードドライブ障害がある場合、Windows 7 UIは応答しなくなります。私のハードドライブの1つはSMARTによる差し迫ったドライブ障害の自己報告であり、Windows 7はそれをマウントしますが、私がそれに保存された特定のファイルにアクセスしようとするたびにハングします。 UIは、ファイルを読み取ることができるか、タイムアウト後にドライブを取り外すことができるまで、最大5分間ロックします(マウスカーソルの動きを除く)。 Windowsがタイムアウトにシステムクロックを使用しているかどうかはわかりませんが、タイムアウト時間を延長できる場合は、時間を固定する必要があるかもしれません。たぶんこれはあなたがそこに途中で行くことになるでしょう、しかしあなたが探している答えを100%ではないでしょう。
これが私が私のデバッグレッスンで使用するアプリケーションのソースコードです。これは、ユーザーモードのアプリケーションがどのようにDoS攻撃を実行できるかを示しています。
マウスカーソルがほとんど動かないことに気付くでしょう(私のマシンでは11秒に1回)。あなたが十分長く待つなら、あなたのPCはまだ電源ボタンに反応するでしょう。
それは無限ループを使用してプロセスに最高の優先順位を設定し(0x100
"realtime")そして最高の優先順位をスレッドに設定します(15
"time critical")。それはそれらのうちの8つを開始するでしょう、それはi7コンピュータには十分です。もっと必要な場合は、ループを調整してください。それらの多くは潜在的に物事をもっと遅くするでしょう。
#include "stdafx.h"
#include <windows.h>
#include <string>
#include <sstream>
#include <iostream>
void WasteTime()
{
int priority = 15;
::SetThreadPriority(::GetCurrentThread(), priority);
while (true)
{
}
}
int _tmain(int argc, _TCHAR* argv[])
{
::SetPriorityClass(::GetCurrentProcess(), 0x100);
for(int i=0; i<7; i++)
{
LPDWORD threadid = 0;
::CreateThread(NULL, 64*1024, (LPTHREAD_START_ROUTINE)&WasteTime, NULL, 0, threadid);
::Sleep(2000);
}
WasteTime();
return 0;
}
このバグ は、リソースの浪費のためにWindowsを非常に早くフリーズします。再現も簡単です。
結局のところ、これは実際に コマンドライン(より具体的には
cmd.exe
)がバッチファイルを解析する方法におけるバグ であり、迅速なサービス拒否につながる可能性があります。タイプ攻撃次の行を(新しい行なしで)バッチファイルに入れると、(この例として)このバグのために非常に早く大量のメモリを消費します。^ nul<^
つまり、キャレットがファイルの終わりにある場合、実際のファイルの終わりは「無視」され、ファイルハンドルは0にリセットされ(本質的に)、バッチが再度解析されます(無限に続きます)。
Process Lassoにバンドルされている CPUEaterユーティリティ を試しましたか? Ps。 bitsumでは動作しません。