תקלת חומרה מעבד חוזר על עצמו? כך בודקים אם מדובר בחומרה — מיד לאחר הפעלת המחשב

איך הבעיה באה לידי ביטוי בפועל:

• קיטוב מיידי בעומס / shutdown עם קוד טמפרטורה ב-BIOS
• Clock speeds נתקעים נמוך גם ב-idle אחרי שינויים
• WHEA errors מעבד/cache recurring בלוג
• Boot loops עם Q-code/debug-LED המצביע על CPU
• ביצועים ב-benchmarks נפלו ~20%+ מההיסטוריה של אותו מכונה

שווה לעצור רגע על השורה הראשונה בטבלה: 'Heatsink hot or cold during trips?' — התשובה עליה (cold+shutdown = contact issue; scorching = cooling capacity) מחלקת את התרחישים לשני עולמות עבודה שונים.

הפרדת התסמין מהשורש חוסכת את התשלום היקר ביותר — משווים בין הפעלה קרה להפעלה אחרי שעות כיבוי. בעסק קטן, תקלה של יום שלם שווה הזמנות שלא נקלטו — אבל פעולה מהירה מדי בלי גיבוי יכולה לעלות ביוקר יותר; התיעוד עושה את ההבדל.

כדי לא לרדוף אחרי כל דבר בבת אחת, הנה מפת הסיכויים של מעבד (CPU) ותקלותו — מהנפוץ בפועל אל הנדיר:

1. הרכבת המקרר נפגעה — פסטה מיובשת, ברגים רופפים, מצע אבק
2. חום יתר ב-VRM גורם לקטיעות תחת עומס ממושך בכל הליבות
3. אי יציבויות מתח מעקובי OC/PBO שהזדקנו באופן גרוע
4. סיליקון מבוגר דורש מתח גבוה יותר לשמירה על תדירויות זהות
5. ירידה באיכות המגע בין הפינים/הכדורים של השקע לבין הלוח במערכות מבוגרות
6. צמצום מכוון (Throttling) המסווה תחת אירועי שגיאה (Prochhot, EDAC, Tjmax)
7. עדכוני קושחה/מיקרוקוד המשנים התנהגות ללא ידיעת המשתמש

המכניקה חוזרת בכל תקלה: שינוי כלשהו קרה (עדכון, התקנה, העברה, הזדקנות רכיב) והמערכת מגיבה. לאתר את השינוי — וחצי מהאבחון נגמר.

ניתן לעצור בכל שלב ולהשאיר את התיעוד בצד — תסמין שמופיע מיד בהפעלה מכוון את האבחון לגורמי אתחול ולא לעומס מצטבר. אין פה שום שלב שמצריך פתיחת המחשב או תוכנה חיצונית.

רמה 1 — symptom classification

סיווג רישום האירועים: כיבוי מול צמצום מול שגיאה - כל אחד מצביע על מסלול אבחון שונה

רמה 2 — thermal truth check

קריאות חיישנים במצב מנוחה/עומס לאימות או לזיכוי תסמיני חום

רמה 3 — configuration neutrality

החזרת הגדרות BIOS ברירת המחדל להגדרות מפעל לקביעת חלון התנהגות בסיסית

רמה 4 — load-stability probing

קטעי עומס מבוקרים למעקב אחר תדירות/שגיאות עם קריטריות עצירה מוגדרות

רמה 5 — platform cross-examination

החלפת קירור/מעבד/לוח לזיהוי גורמים שורדים לאחר שלילת תקלות תוכנה

ההיגיון מאחורי הסדר פשוט: הרמות הנמוכות בטוחות והפיכות, הגבוהות דורשות משמעת. אבחון תקלת חומרה מעבד עבור מחשב שולחני — עסק קטן — שלב: מיד לאחר הפעלת המחשב לא מחייב כלי אחד ספציפי — הוא מחייב שלא תדלגו בין רמות בלי לתעד מה נבדק ומה המסקנה.

אלה הצעדים שמומלץ לכל אחד בלי ידע מוקדם: אפס סיכון, ערך אבחוני גבוה. סדר ותיעוד הם כל הסוד:

1. תרשים חום במנוחה: רישום טמפרטורת החבילה במצב מנוחה לאחר זמן התייצבות

1. טעינה קצרה של המעבד תוך פיקוח על טמפרטורות ותדירויות — כל הגבולות המוגדרים מושגים במדויק:

1. קריאת נתוני ה-BIOS: ערכי המתח והטמפרטורה המוצגים על ידי קושחת הלוח נלקחים תמונת מסך לתיעוד:

1. סקירת יומן ה-WHEA: אירועי שגיאות חומרה נרשמים בשיטתיות:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 15 -ErrorAction SilentlyContinue

1. בדיקת תחזוקה עברית: תאריכי טיפולים קודמים (החלפת פסטה/מקרר/אבק) נבדקים לפי קבלות וזיכרון מקצועי:

אין שינוי אחרי כל הבדיקות? זה לא נזק — זה חצי אבחון. עוברים לרמות העומק.

סשני רישום ממושכים תחת עומס: נתוני טלמטריה ארוכי טווח משווים בין טמפרטורות/תדירויות/הספק כדי לזהות חתימות של צנטור:

חלוקת סוויטת המאמצים: פרופילי עומס שונים מבדילים בין עבודות עם AVS כבדות לקלות, מגדירים גבולות אי-יציבות בבירור:

בדיקות קוד מיקרו וקושחה: רשימות שינויים של היצרן מתואמות עם גרסאות ה-BIOS המותקנות, חושפות שינויי התנהגות שקטים:

בדיקת איכות המגע: ניתוח דפוסי הפסטה בהרכבות מחדש מצביע על אחידות הפילוס באופן מקצועי:

מטריצות החלפת פלטפורמה: מעבדים ומקררים חלופיים מותקנים בצורה שיטתית, הופכת השערות לממצאים סופיים:

כלל פרשנות אחיד: ממצא שאינו ברור לא מזיז את המחט; מה שכן — השוואה: תקין מול תקול, לפני מול אחרי, מחשב זה מול אחר.

עבור עסק קטן, הסט הזה מכסה את רוב צרכי האבחון מבלי להתקין דבר חדש; אם כלי נראה מאיים או לא מוכר — דלגו עליו וחזרו אליו אחר כך.

הסימנים מצטברים לכיוון, הכיוון מצטבר להחלטה — ורק כשזה ברור עוברים לפעולה על רכיב.

מה התסמין אומר — ומה הוא לא אומר

נטייה טבעית היא לחשוד מיד בCooler mounting degraded — dried paste, loosened brackets, dust mats — וזו נקודת פתיחה סבירה. עדיין, התסמין שמתואר (כיבויים תחת עומס, קריסות חוזרות ללא הסבר תוכנתי) יכול לנבוע גם מVoltage instabilities from marginal OC/PBO curves aging badly או במקרים הנדירים מFirmware/microcode updates shifting behavior silently: לכן הסדר קובע ולא האינטואיציה בלבד.

זכרו שתיקון ראשון שנראה מצליח אינו תמיד פסק דין: לפעמים הוא פשוט מעביר את הבעיה לרקע. עקבו אחרי המערכת יום-יומיים ורשמו — התסמין חזר? השינוי חשף בעיה עמוקה יותר.

בעל עסק קטן שבו המחשב מרכז את כל ניהול ההזמנות והלקוחות נתקל במשרד העסק בדיוק בתרחיש הזה: כיבויים תחת עומס, קריסות חוזרות ללא הסבר תוכנתי. התהליך נפתח ברישום — מתי התסמין מופיע, מה קודם לו, מה כבר נוסה. משווים בין הפעלה קרה להפעלה אחרי שעות כיבוי.

אחרי שרשרת הבדיקות הבסיסיות לא מצאה אשמה מובהקת, טבלת ההשוואה רמזה לכיוון: התופעה נמנעה תחת תנאי אחד וחזרה תחת אחר. שתי האפשרויות שנותרו הופרדו באימות בודד, והתיקון — ממוקד. בלי הסדר, התהליך היה מסתיים בהחלפת רכיבים יקרה ומיותרת.

השורה התחתונה של התרחיש: בעסק קטן, תקלה של יום שלם שווה הזמנות שלא נקלטו — אבל פעולה מהירה מדי בלי גיבוי יכולה לעלות ביוקר יותר. התהליך המסודר לקח פחות זמן מניסוי וטעייה, והותיר רישום ששימש גם בהמשך — אצלכם או אצל הטכנאי.

• Reseating campaigns without proper paste supplies running dry-mount cycles briefly
• Over-tightening cooler brackets warping boards/socket interfaces subtly
• Voltage bump experiments on already-degraded samples accelerating decline
• Blocking airflow zones while 'testing' bench-style configurations
• Ignoring repeated thermal-shutdown events continuing heavy renders regardless

נושא זה מסומן במערכת התוכן כדורש זהירות מיוחדת — הסיכונים כאן כוללים נזק בלתי הפיך לנתונים, לציוד או לבטיחות הפיזית. הכלל: בספק — עוצרים.

• Continuing overclock experiments atop active instability logs compounding forensic noise
• Multiple remount cycles back-to-back exhausting paste beds wastefully
• Cleaning heatsinks while system powered/connected anywhere near
• Substituting coolers across incompatible sockets forcing mounts destructively
• Disabling protective thermal features to 'finish' tasks flirting disaster directly

היקף המדריך: deep-dive בשלב אבחון בודד בלבד; אינו חוזר על בדיקות בסיסיות המפורטות במאמר-האב ARTICLE-0641; חובה קישור-חזרה למאמר-האב

סמנו כל סעיף לפי המצב בפועל — זו התמונה שתלווה אתכם בהמשך:

1. תיעוד הפער בין התנהגות מיד אחרי הפעלה לבין התנהגות אחרי זמן
2. Temperature/error-event timeline plus maintenance history attached documenting causality
3. כל בדיקות הבסיס הורצו לפי הסדר ותועדו עם תוצאתן
4. שונו לכל היותר הגדרה אחת או שניים — ורשום מה בדיוק
5. נבדקה קיומו של גיבוי עדכני לנתונים החשובים
6. הוגדר מה נשלל ומה נשאר חשוד
7. הוחלט: ממשיכים לבד, מרחוק בהנחיה, או טכנאי
8. אם יש נקודת עצירה מהרשימה למעלה — היא גוברת על כל השאר
9. הוגדר מה בהיקף של אבחון תקלת חומרה מעבד עבור מחשב שולחני — עסק קטן — שלב: מיד לאחר הפעלת המחשב כבר נבדק ומה נותר מחוץ לבדיקות שבוצעו
10. תיעוד המדריך (סימוני צ'ק-ליסט + צילומי מסך) נשמר בקובץ או בתיקיה שאתם תמצאו שוב

CPU-class faults narrate through temperatures, error families, and stress responses; disciplined taxonomy converts panic into organized next steps.

Neutral-default baselines remain the profession's great equalizer — most 'dying processor' alarms resolve into mounting, dust, or voltage-curve stories quietly.

When platforms genuinely age into instability, substitution benches deliver certainty swiftly — protecting workflows from death-march triage cycles indefinitely.

חיבור הנקודות לסדר יום: התסמין (כיבויים תחת עומס, קריסות חוזרות ללא הסבר תוכנתי), שלושת החשודים הראשונים מהרשימה, ושיטות הבדיקה מהסעיפים למעלה — אלו שלושת הרכיבים שהופכים בלבול לתוכנית.

שלוש יציאות אפשריות מהמדריך הזה: פתרון מלא בעצמכם, המשך הנחיה מרחוק, או העברה מסודרת לטכנאי עם רשימת הממצאים. הממצאים סביב חשד לתקלת חומרה במעבד הם שיקבעו לאיזו מהן נתקלתם.

סיימתם את השלבים בלי פתרון? זה לא כשל שלכם — זה בדיוק הרגע שבו ציוד מקצועי ועיניים טריות חוסכים ימים. קחו את רשימת הממצאים שאספתם והמשיכו לחלק של שירות מקצועי בהחלטה מושכלת.