Windows10のディスクアクセス100%でフリーズ問題 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
タスクマネージャーの「ディスクのアクティブな時間」が100%に張り付いてOS全体の動作が劇重になる問題について
Microsoftのフォーラムでも数々の報告があります
https://answers.microsoft.com/ja-jp/windows/forum/windows_10-performance/windows-10/3930002c-ad00-40e2-b1fb-52046ddf734e?page=1
・フリーズした後はイベントビューアに「デバイス \Device\RaidPort0 にリセットが発行されました。」のエラーがある
・SATAドライバがIntelのiaStorA、マイクロソフト標準ドライバのstorahciでも起こる
対処法としてググるとよく挙がる
・SATAドライバのLPMを無効にする
・BIOSでSATAのホットプラグを有効にする
をやっても直らなかった人、対策を語り合いましょう >>703
bios8.0でフリーズ解消しました。 毎日使っているマシンなら調子がいい。
メインマシンはほぼ毎日動かしているから、遅くならない。
たまにしか動かさないマシンでは、ディスクアクセス100％で遅い＆フリーズ、ひどい場合はブルースクリーンで落ちる！ ないわ>たまにしか動かさないマシンでは、ディスクアクセス100％で遅い＆フリーズ、ひどい場合はブルースクリーンで落ちる！
つかそのPCが壊れてるダケ
要はおま環 メモリ8GBなのに何でディスク100使うの？メモリが100で足りないならディスク使うの分かるが マザボ入れ替えたらこの症状出てしまった
ググってレジストリいじったりして電源オプションを高パフォーマンスに
したら落ち着いた
バランスにすると途端に100%になる 面倒なのでそのまま流用した
今の所症状出ないので手に負えなくなったら考えるよ 宇宙膨張の正体は重力回転遠心作用
http://i.imgur.com/YEnf3Rc.jpg
重力によって引合うが、外側へ飛んで行くルートはある
http://fnorio.com/0085swing_by_navigation1/fig3-3.GIF
場合によってはスパイラルな星団推進力を持つ
http://i.imgur.com/VFRB2GV.jpg
重力によって物体間で引合い場合によっては回転する
さらに場合によっては軌道を外れ遠心力で飛ばされる
飛ばされたなら空間が膨張したかのように見える 気のせいという実害がある不具合。
不具合に慣れきった生活。
Windowsでの一番の仕事はWindows Update。 Intel 100シリーズだとまったく問題ない
同じSSDをB450のRyzen 2600システムに移植したらLMPフリーズ問題が発生した
もちろんOSはクリーンインストール
SSDはハード/OS両対応のBX300とハードにしか対応していないMX500の混載
>>1はインテルがどうの書いてるけど、AMDerのステマだよ マザーの型番は何？>B450
BIOS更新はやったのか？ メーカーのノート用中身マザーボードとかcpuとか全部変えたらいくらぐらい？DVDドライブ要らないSSDは既に買ってあるメモリは今使ってるのを利用したとして 技術者のパソコンでなる可能性が高いってことはないかな？
つまりはAdobeの製品やVisual Studioがインストールされているパソコンなど。 メモリ２GBしかないのに仮想メモリを6GBにしたらかなり重くなった >>5を試したらフリーズしなくなった
updateのせいで重くなってたんだな 仮想メモリって何なんだろ物理メモリ8GB積んでてもswapするし仮想メモリなしにしたからって速くはないし >>720
>>723
なにこれ、初心者を装ったネタ？ 初期化して
数日は平気だったが
また100、外付けhddを付けると50
どっちにしても激重には変わりなし
東芝のサポートも頼りならないし
いっそのこと買い替えようかな
まだ3年経ってないのに >>1
WindowsがいまだにMs-DOSだからだよ
https://srad.jp/story/19/05/09/0526247/
ファイルが破損しやすいのはこの辺りが原因です。 上のリンクの掲載リンク
＜長文＞Windows のファイルのコピーは、驚くほど奥が深い。
https://www.facebook.com/dnobori/posts/2142836202459674
100％になりやすいのは無駄な処理が行われてるため ストレージメモリが物理メモリのスピードに勝る日はいつくるかね >>727
中身のない
中学生の反省文みたいだ
Facebookが駄目になったのは
こういうつまらないのが溢れたからだな Windows のファイルのコピーは、驚くほど奥が深い。
Windows で、ファイルやディレクトリのコピーなど、ファイル操作のコードを書くときは、決して油断してはならない。
UNIX の開発者が Windows の世界にいざ足を踏み入れるときなど、Windows の素人は、以下のすべての点について、当然、万全の注意を払わなければ、大変なひどい目に遭うのである。
(1)♪ 当然、ファイルやディレクトリのパス文字列は 260 文字を超える可能性があるのだから、当然、先頭に謎の呪文である
"\\?\" という文字列を付加する必要がある。これにより最大約 32767 文字までのパス名を取り扱えるようにすることを忘れるな。
(2)♪ 当然、コピー先パスにすでにファイルが存在しており、かつ、ファイルが「読み取り専用」属性になっている可能性があるのだから、
十分警戒しなければならない。もし「読み取り専用」属性になっていた場合、上書きすることはできない。ファイルを書き込み可能モードで開こうとする前に、属性を解除することを忘れるな。
(3)♪ 当然、コピー元ファイルには代替ストリーム (Alternate Stream) が含まれている可能性がある。代替ストリームとは、
あの Windows でよく見られる、Web ブラウザでダウンロードしたファイルをダブルクリックすると「本当に開きますか？」と
確認画面を出す機能の裏側で利用されている、1 つのファイルの本体データのほかに任意の個数の隠しデータを保存する機能である。
昔の Mac でいうリソースフォークである。代替ストリームは 1 つのファイルに何百個も付いている可能性があるし、
サイズも制限がないが、これを忘れずにコピーしなければならない。なお、あるファイルに付いている代替ストリームの
一覧を列挙する API は「FindFirstStreamW」であるが、素人の中には、これを使ってただただ安心している者が多い。
しかし、これには重大なワナがある。(11) で述べる。 (4)♪ 当然、コピー元のファイルやディレクトリの「作成日時」、「更新日時」、「アクセス日時」をコピー先にコピーすることを怠ってはならない。
ただし、ファイルシステムの種類によって、これらの日時の精度が異なるので、これらの情報に基づくファイル同期コードを書くときには、
ある程度の時差を許容するコードを書くことを忘れるな。そうしなければ、毎回、日時が変化しているように見えてしまうのである。
(5)♪ 当然、ファイルコピー時にコピー元ファイルの属性ビットをコピー先にコピーしたからといって、それだけで油断してはならない。
ファイルコピーにおける各種の書き込み操作で、コピー先ファイルに「アーカイブ属性」が自動的に付いてしまうことがある。
各種操作をした後、最後に「アーカイブ属性」をもう一度確認してコピーすることを忘れるな。
(6)♪ 当然、ファイルの属性をコピーするとき、単なる「属性フラグ」では操作することができない、
「特殊な API でしか読み書きできない特殊な属性フラグ」が元ファイルや元ディレクトリに設定されているかどうか、
チェックしなければならない。具体的には、圧縮ファイル属性、「シンボリックリンク属性」、「ジャンクション属性」である。
(7)♪ 当然、元ファイルまたは元ディレクトリは、シンボリックリンクである可能性があるから、
コピー時は必要に応じてこれを再現しなければならない。なんと、Windows にはシンボリックリンク的な実装として、
シンボリックリンク」と「ジャンクション」の 2 つがある。そして、これを見分ける方法は通常のファイル API には存在せず、
通常のファイル API を用いるとリンク先のファイルやディレクトリが透過的に見えてしまう。そこで、プロは、
DeviceIoControl API を用いて「シンボリックリンク」または「ジャンクション」の生のメタデータにアクセスするのである。 (8)♪ 当然、元ファイルまたはディレクトリには「NTFS 圧縮属性」が指定されている可能性があるから、
コピー先に対してもこの属性を再現する必要がある。そうしなければ、保存先のディレクトリの属性が適用されてしまう。
ところが、この属性は標準のファイル API では設定することができず、なんと DeviceIoControl で特殊な方法を用いて
属性を設定する必要があるのである。そして、圧縮属性は、すでにデータがあるファイルに対して適用しようとすると、
大変長い時間がかかる上に、Windows のバグ (仕様 ?) として、CancelIo というキャンセル用 API が効かない
(つまり、一度圧縮を開始してしまうと、Windows を強制シャットダウンするしか、圧縮処理を中断できない) という問題があるので、十分に警戒をしなければならない。
(9)♪ 当然、元ファイルは NTFS の暗号化ファイルシステム (EFS) によって暗号化されている可能性がある。
そして、暗号化がされている場合、① ファイルをコピーしようとするユーザーがその秘密キーを有しているケース、
② 秘密キーは有していないが管理者権限を有しているケース、③ 秘密キーは有していないし管理者権限も有していないケース、の
3 通りが考えられる。そして、ユーザーの希望により、[A] ファイルを一度メモリ上で復号化し、再暗号化して保存して欲しい場合、
[B] ファイルを復号化せず、暗号化された生ストリームのままビット列としてコピーしてほしい場合、
[C] ファイルは復号化し、コピー先では平文ファイルとしてほしい場合、の 3 通りが考えられる。
この 3 × 3 = 9 通りのすべてのパターンで、可能な限り正しくファイルをコピーすることが、プロには求められる。
② のケースでは、ReadEncryptedFileRaw を用いて、鍵を持っていなくても、暗号化された生の物理的なビットデータのコピーが可能であるから、プロはこれを活用するべきである。 (10)♪ 当然、元ファイルまたは元ディレクトリ、または先ファイル・先ディレクトリへのアクセスの際に、
NTFS で ACL が設定されていることから、アクセス権が無い可能性がある。これはローカルの場合も、
ネットワークファイル共有上の UNC パスにアクセスする際にも、同様である。しかしながら、
ユーザーは一般的にファイルをバックアップ / 復元するためにコピーをするのであるから、当然、
NTFS によるローカルまたはリモートのアクセス制限は無視してコピーしなければならない。
このようなことは一般的には禁止されているが、AdjustTokenPrivileges などの API を用いてバックアップ特殊権限を有効化した後、
CreateFile API において FILE_FLAG_BACKUP_SEMANTICS を指定してファイルやディレクトリを開くことにより、
NTFS の ACL を完全に無視してファイルの読み書きが可能になるのである。Windows のプロは、
当然、このようなことをするコードを、無意識に書くことができるはずである。
(11)♪ 当然、(3) で説明した代替ストリーム付きファイルのコピー処理を行なおうとする際に、
コピー元ファイルが NTFS によってアクセス制限されている場合は、(3) で説明したアクセス
権限無視の特殊モードを有効化する必要があるが、なんと、(3) で説明した FindFirstStreamW API を
用いた代替ストリーム一覧の列挙処理においては、NTFS のアクセス権限を無視して列挙ができない。
これは明らかに Windows のバグ (仕様 ?) であり、全くけしからんことである。Win32 SDK の API
ドキュメントを見渡したが、NTFS のアクセス権限を無視した代替ストリームの列挙を可能とする API
は 1 つも存在しなかった。それでは Windows 標準の ntbackup (Windows XP まで付いていた) は
どのようにして NTFS のアクセス権限を無視した代替ストリームのコピーをしているのか? また、
「BackupExec」などの市販ソフトではどのように対応しているのか? ここで Windows のプロ必携の
逆アセンブラの出番である。調査したところ、なんと、非公開 DLL「ntdll.dll」の「NtQueryInformationFile」
を用いて、NTFS 権限を無視した代替ストリームの列挙が可能な機能が実装されていたのである。 >>730
UNIX の開発者が Windows の世界にいざ足を踏み入れるときなど、
Windows の素人は、以下のすべての点について、当然、万全の注
意を払わなければ、大変なひどい目に遭うのである(以下略)
↑ビジネス文書なら、駄目だしくらう以前のレベルだなあ
てにをはがの使い方がなってないうえに、無駄かつ余計な表現やくりかえしが多く、読者を混乱させるだけ
添削例
UNIXの開発者がWindowsのプログラミングを行う場合や、プログラミング未経験者
などは、以下の点に留意しておく必要がある
1.先頭に"\\?\" という文字列を付加することにより、最大約 32767 文字までのパス名を取り扱えるようにできる。
これは、ファイルやディレクトリのパス文字列が 260 文字を超える可能性があるためである。 うちの富士通製のPC、2台のHDDによるRAIDなんだけど、これが最近のWindows10でHDD100%になる。1511大丈夫だった記憶が。 おいこのフリーズ連発のゴミクズOSをつくった野郎はどこのどいつだ？？？ 一昨日、ノートPCでWindows Update当てたけど今朝から今までずっとディスクアクセスが１００％のところで張り付いたままになってる
corei3+HDD環境だから>>666の言う通り時間がかかるんだろうけど丸一日もこのままなのは辛い... 1週間前の書込にレスするのもなんだけど、そこまで酷い状態ならクリーンインストールなり購入時の状態に戻すなりしたほうがいいと思う。 WindowsはOSがしょぼいのが原因で簡単にメモリーが不足したり
限界値が低いので簡単に応答なしになる。
単純作業用で込み入った使い方は向いてない。
向いてない使い方はしない方がいい
そこを改めることから始めないとだめかと
昨今勝手に使わない機能を盛ってくることもメモリー不足の原因だし
最早WindowsMEと一緒です。やる事は同じで機能を外す事が対策になります。 >>736
なんの話をしているかわからない。
サーバーなのか普通のWindowsで行なっているかわからない
RAID1だとソフトウェアRAIDぽいが
それだと普通に遅くなるので処理が余裕がないと悪化するだけですよ。
しょぼいRAIDならRAID0にでもしたら？
WindowsはOSが使えないので単純作業に徹する事
メモリーが足りなくなることを避ける。
ディスクキャッシュが使えなのでSuperFetchは切る
これを行なってみる。 来年はWindowsが穏やかでありますように・・・ このディスクアクセス100％の問題な
会社の情シスで詳しいやつに個人的に聞いたらHDDやSSDの寿命を縮めるって言ってたな
個人情報よりまずそれが糞だと >>746
HDDの場合、その状態で4、5日位放置すると壊れるね
個体差で2、3日でダメかも知れない
SSDではまだなった事ないな >>730
reagentc /setreimage /path \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE >>748
この程度の内容が理解出来るレベルならばそれだけでもプライドだけは高い知ったか除けのお守りにはなるよね storahci.sysが10.0.18362.693に更新されたが更新履歴に記載されてないんだよな何が更新されたんだ
https://support.microsoft.com/ja-jp/help/4535996 >>1
Windowsの仕様だ。
マイクロソフト低脳システムが貧弱なので
閾値を超えると突然応答なしになる。
原因はOSがディスクに依存するシステムであることで
そのキャッシュシステムが足を引っ張っているのでoffにすることで改善する。
superfetch（Windows8以下）、SuperFetch（Windows10）
これを無効設定することで若干遅くなるが応答なしから回復が早くなるので
通常無効設定の方がイラつくことはない。 スーパーフェチをオフにするって超アタマ弱いtweakと思いますケド ぶっちゃけH/W障害っす>ディスクアクセス100%問題
なんでもかんでもwinのせいにすりゃ済むヤシってホント楽チンな生き方してると思うワ これなぁw
確かにWindowsは子供用。
アプリを４つとか５つとか複数アプリを組み合わせていると発生するので、
単純な作業で終わる内容なら有効
かなり連携作業を行うユーザーなら切っていた方が有効。 出費ケチってキャッシュの少ねえ廉価版の淫石使ってるからそんなブザマなコトになんだよハゲ うーん・・・
>>760
CPUのキャッシュ以前の問題です。
Windowsのディスクキャッシュの作りが悪い問題です。
ゴミなので使えないって話。
要は子供用ですよ。Windowsはディスクに依存するのでディスクのアクセスを
キャッシュで早くする目的だが、実際には簡単なことしかできない。
作りが非効率でキャパを超えると著しく遅くなる。
組み合わせてものづくりをする人向けではない。
逆にゲームしかしない消費型の連中は有効にすべきっていう話。 使えないディスクキャッシュなので
SSD使っているならさらに不要
考えて見ればわかるでしょ 何その謎理論
SSDよかメモリの方がゼンゼン速いんだが Windowsはお子様用で
使えないって言われるでしょ
前提条件完全無視ですか？
お馬鹿さん バカはコメントを書く前に
Windowsが応答なしになる理由を考えましょう
このスレの主旨は応答なしの策であることを
お忘れの様ですのでw そも応答なしは糞淫のCPUが原因って書いてやってんじゃん 自動メンテナンスを手動で実行したところ10分くらいしたところから途中でフリーズしてしまい完了できません。
環境は…
7からのアップグレードです。
内部HDDは4台、拡張USBをマザボに付けてます。
外付け1台付けます。
メモリ8G
簡単な説明ですが、メンテを完了させるにはどうすればいいですか？ >>768
強制終了させた上で再起動してOS上から修復インストールしましょう >>769
なるほど…
ありがとうございます。
明日やってみます。 修復インストールして、手動でメンテナンス実行したが、今度はカーソルのグルグルがもう30分治まらない。
結構期待したがダメだった。
また、7に戻そうとしたら戻せなくなった…ｵﾜﾀ
でも自動メンテが、ガンなのは分かった。
誰か助言を… >>771
ハードディスク環境ならばアクセスランプが点滅しているのであれば３時間は待ってみる
最初の一回目はもの凄く時間がかかるものです >>772
ありがとうございます。
そうなんですが、初期状態になってしまうので、それはそれでかなり面倒なことに…
でしたら、Win10のクリーンインストールで改善できるのか調べてみます。 >>773
アクセスランプ点灯しっぱなしです。
うちSSDなんですけどね。
でも、もう一度挑戦してみます。
皆さん、ありがとうございます。 2020may、updateで解決済って日経PCの雑誌に書かれていたんだが・・・ 長年色々と検証してきたけど、ディスクアクティブ100%現象はストレージの不良セクタもどきが悪さをしている可能性が高いな
ドライバへのアクセスをロックしているようです
HDAT2のブートディスクを作成して極端にスループットが落ちる箇所がないかを確認してみるといいですよ
純粋なDOS環境で動作するのでUEFIからではブート出来ませんから、レガシーブートを利用します >>792
もどきって何だよｗ
不良か不良でないかのどっちかだろSSDでも発生するのに。
セクタ不良ならディスクスキャンで発見されるはずだがそれやっても異常なし。
Windowsの何かのバクなのは確定なんだよ。 HDDとSSDの原理の違いすらわからんアホがこの板には常駐してるのか
さすがWindows板 代替処理済みのセクタと代替保留済みのセクタの意味が違うのもわかっていないものなw
ファームウェアが不良だと代替されずにずっと保留済みのセクタとして発生し続けるようになるんだよ
これが所謂、書き込み時のパリティチェックには問題がなくても、後々読み込み時に中身が化けてしまう不良セクタですよ
簡易フォーマットをすると一時的にS.M.A.R.T.で見えなくなるので結構とトラブルの原因となります >>797
保留済みセクタがSSDで発生するかアホ >>798
理論的にはあり得ます
あんたのSSDにはS.M.A.R.T.の項目に表示されていないだけ SSDの場合にはブロック単位で書き込みしていて読み込み時にはページ単位でパリティチェックをするので
化けている場合にはそのブロック単位で保留済みになってアクセスしなくなるでしょうけど、
例外はあるでしょうが、通常この様な場合には不良ブロックとしてファームウェア側で代替しているようです ユーザー領域としての全LBAアドレスと言うのは表明チェックソフトで全セクタのパリティチェックで見えているものです
ここで赤の不良セクタと判断しているものは、読み込み時に中身が化けていると判断されているものです
よく勘違いしているのが、これはファームウェア側で予備領域と代替してくれていれば現れなくなるものであるという事で、
表面チェックでは見えなくなります HDDと違ってSSDは一度読み込みに失敗したら複数回読み込み試行しても変化はないので
即代替するファームウェアがほとんどだけどね。
てか、そうでないファームウェアがあるならどこのメーカーのどのSSDか教えてほしいわ。 >>792
store関連のサービスとか普通に優先度が高すぎ。 大体さ、HDDのクラスタ読み込み失敗で再試行を繰り返す時のアクセスランプの光り方と全く違うのに
「それはSSDのせいだWindowsのバグじゃない」
と言い張るやつって何なの？
Windowsがおかしいのは見りゃわかるだろバカが。 ■ このスレッドは過去ログ倉庫に格納されています
