3rdに引っ越しました。 2010/12/31 以前&2023/1/1 以降の記事を開くと5秒後にリダイレクトされます。 普段の日記は あっち[http://thyrving.livedoor.biz/] こちらには技術関係のちょっとマニアックな記事やニュースを載せます。 Windows2000ネタ中心に毎日更新。 Windows は desktop.ini というファイルに特別な情報を入れて、システムファイル属性を付加するといろいろなことができます。 よく知られているのは InfoTip を付けると、フォルダの情報を表示することができること。 IconFile や IconIndex でフォルダアイコンを変更することができること。 LocalizedResourceName でファイル名のエイリアス(XP以降) などがあります。 あまり知られていないのは ConfirmFileOp=0
以前は有料ソフトであり、ロードテストを実行した結果を数値・グラフ化してまとめて保存でき、サイトへのアクセス順番を固定したりランダムにしたり、アクセスする時間間隔・接続時間・アクセスする人数の設定が可能で、さまざまなテストを自由に設定して実行できるフリーソフトが「JBlitz Professional」です。ダウンロードから機能と操作の説明までは以下から。 Website load test - JBlitz Professional http://www.cartesian.net.nz/jblitz/ ◆ダウンロード 「JBlitz Professional」を使うにはJavaをインストールしておく必要があります。 上記サイトの「Download」をクリック。 ダウンロードしたZIPファイルをExplzhなどで解凍して、Windowsを使って操作をするので「run-jblitz.bat」
Win32 API (のファイル操作系)を叩く際に気になるものとして MAX_PATH の存在があります.例えば,MoveFile などの関数においても指定されたパスの長さが MAX_PATH (256 文字?) を超えると失敗します.ただ,この制限はパスの頭に "\\?\" と言う文字列を追加すると緩和されるそうです. Windows NT/2000:この関数の ANSI 版では、名前は最大 MAX_PATH 文字に制限されています。この制限をほぼ 32,000 ワイド文字へ拡張するには、この関数の Unicode 版を呼び出し、パスの前に "\\?\" という接頭辞を追加してください。詳細については、MSDN ライブラリの「」(ファイル名の規則)を参照してください。 MoveFileEx 関数 - MSDN このオプションが気になったので,実際に接頭辞を付加して実行してみた結果が以下の
最近のコンパイラは、かなり頭の使う処理を行ってくれています。VIsual Studio でも、普通に書いたプログラムなのに、いろいろなセキュリティー関連のチェック機構を埋め込んでいくれています。動作させる環境を守ってくれるのでとても有難いのですが、何も知らずにプログラムを使っていると、思わぬところで悩まされることがあります。 Visual Studio で /GS オプションを付けて C/C++ プログラムをコンパイルすると、関数呼び出しの際にバッファー オーバー ラン (BOR) を自動的に検出してくれるコードが埋め込まれます。異なるバージョンのコンパイラで作ったライブラリをリンクさせようとすると、たまに 「__security_check_cookie なんちゃらのシンボルがない」 というリンク エラーが出ることがあります。自分で書いたプログラムを見てもそんな関数は使ってないわけですが
XNA デベロッパー コネクション (XDC)、ソフトウェア デザイン エンジニア Chuck Walbourn 著 2005 年 12 月 はじめに 最近のコンピューターで電源管理技術の普及が進んでいることにより、高精度の CPU タイミングを取得するための一般的な方法であった RDTSC 命令が、予期したとおりに機能しない場合があります。ここでは、Windows API の QueryPerformanceCounter と QueryPerformanceFrequency を使用した、より正確で確実な解決策を示します。 背景 x86 P5 命令セットの導入以降、多くのゲーム開発者が高精度タイミングを実行するために Read Time Stamp Counter (タイム スタンプ カウンターの読み取り) つまり RDTSC 命令を使用してきました。Windows マルチメディア タ
最大CPU数が4096、最大ノード数が512まで拡大されました。 Windows7 の 256 プロセッサ対応は全然負けてるねw x86の最大CPU数、最大ノード数が拡大 最大CPU数が4096、最大ノード数が512まで拡大されました。当面はSGIのx86_64スパコンくらいでしか意味がなさそうですが、カーネルデベロッパーから見ると、事実上、cpumask_t変数をスタックに置くことが全面禁止になってしまったことを意味します(スタックが4Kbytesしかないのに、1変数あたり512bytesの変数を置くなんて……) そういえば,昨晩の WinHEC 2008 2日目のキーノートで,Windows Server 2008 R2 を使った 256 CPUs デモが行われていた. http://wm.istreamplanet.com/customers/ms/750_ms_winhec_081
Windows の Timer について † 結論:正確な時間計測には QueryPerformanceCounter(), QueryPerformanceFrequency() を使いなさいってこった。 High Performance Timing under Windows (http://www.devsource.com/ ) 元ネタ。 GetTickCount()、SetTimer() + WM_TIMER † Windows はリアルタイム性を強く求めていないので、Timer としての精度は悪い。 WM_TIMER の優先順位はかなり低く、他のプロセスに CPU パワーの優先順位が高く割り当てられている等の場合、100ms 程度の制度しか期待できない。システム全体のパフォーマンスの均一化によるパフォーマンスの向上を考えると一概に悪い仕様とは言えないだろう。 逆に 100ms
Writes user-mode minidump information to the specified file. Syntax BOOL MiniDumpWriteDump( [in] HANDLE hProcess, [in] DWORD ProcessId, [in] HANDLE hFile, [in] MINIDUMP_TYPE DumpType, [in] PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam, [in] PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam, [in] PMINIDUMP_CALLBACK_INFORMATION CallbackParam ); Parameters [in] hProcess A handle to the process for w
Important The minidump code has evolved greatly over the years since its inception. Many of the constants listed on this page were added later and are not available in all versions of DbgHelp.dll. Those that did not exist in the original code are labeled accordingly along with the version of DbgHelp.dll that they first were implemented in. The listed version numbers corresponds to the Debugging T
id: 918 所有者: msakamoto-sf 作成日: 2011-02-13 12:05:13 カテゴリ: Windows プログラミング [ Prev ] [ Next ] [ 技術 ] Windows XP SP3, Windows 7 上でのメモリダンプ取得方法メモ。 基本的に "Debugging Tools for Windows" 無しの状態を想定しています。つまりユーザー環境でアプリケーションクラッシュやハングアップ、あるいはBSODが発生した瞬間を捕まえるための設定をメモしていきます。 なお一部のシナリオではMicrosoftから公開されている"UMPD : User Mode Process Dumper"というツールを使っています。 以下の環境で動作確認しています。いずれも日本語版のWindowsを使っています。 Windows XP SP3 : x86(32bi
MiniDumpWriteDump を使用する際、ターゲットではなく、キャプチャ プログラムのアーキテクチャに対応するダンプが作成されます。そのため、32 ビットのプロセスをキャプチャする際は 32 ビットのキャプチャ プログラムを使用し、64 ビットのプロセスをキャプチャする際は 64 ビットのキャプチャ プログラムを使用します。"64 ビット版 Windows 上の 32 ビット版 Windows" (WOW64) をデバッグする場合は、32 ビット プロセスの 64 ビット ダンプを作成する必要があります。 (意図的かどうかを問わず) アーキテクチャと対応していない場合、64 ビット ダンプで 32 ビットのスタックにアクセスするために、デバッガーで対象のコンピューター (.effmach x86) を変更する必要があります。多くのデバッガー拡張機能ではこのシナリオを実行できないので
アクセス違反などでクラッシュして終了したプロセスのダンプをデバッガで開くと、 クラッシュしたスレッドにコンテキストがセットされた状態で開かれます。 このため、ひとめみただけで、クラッシュの直接の原因を特定することが可能です。 その直接の原因にいたる経緯はひとめではわかりませんが、なぜアクセス違反を発生させたのか、などは ひとめでわかります。 「ひとめでわかる」 と言われても、デバッガを使ったことが無ければ、 なかなかピンとこないと思いますので、簡単な例をみてください。 クラッシュ時の解析例 次のようなコードがあったとします。 #include <string.h> int main() { strcpy( NULL, NULL ); return 0; } このコードでは strcpy 関数を呼び出していますが、文字列の元のアドレスも書き込み先も NULL がセットされています。 NULL
Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature. This feature is not enabled by default. Enabling the
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く