Bought the Right Machine and Maintained It, Yet It Keeps Failing Mid-Semester? Advanced Student Guide: Triage, Deadlines, Evidence, and Replace-or-Endure Decisions

Premise: an advanced guide, only for cases where the basics are already done

The earlier guide, Student Laptop Guide: What to Buy, How to Maintain It, Dropped or Soaked — Repair or Replace (Chinese library number 115, English library number 116, short address student-laptop-guide), already covered the subject-based buying baseline, student discounts, five common faults, drop and liquid first aid, battery and cooling care, backup rules, and the fifty-percent repair-or-replace rule. This article cites that premise in one place only and does not rewrite those basics. It assumes the reader has already followed that buying and care advice, yet the machine still keeps failing mid-semester, and only then uses the advanced methods below. The single question is this: when a machine does not fail once but fails repeatedly during term, how do you stop starting from scratch every time?

Core distinction: one incident, or one problem

IT service management draws a basic distinction worth stating before any triage. An incident is a single unplanned interruption, where the goal is to restore normal operation quickly, not necessarily to find the root cause. A problem is the cause behind one or more incidents, where the goal is to find that cause and prevent recurrence. Applied to a student machine, fixing it once is incident handling; the same fault appearing again is a signal to open a problem investigation, not to treat every repair as an isolated event. This distinction is the dividing line for the whole article. If triage shows every fault is different, handling each one separately is correct. If it shows the same symptom recurring, switch to the bring-the-evidence mode, rather than repeating only that it broke again.

Mid-semester recurrence triage: three paths

Path	How to recognise it	Key evidence	Next step
A. Same fault recurring	Symptoms, triggers, and affected parts are the same every time, for example the same key failing, or shutdown under the same condition	The old repair ticket stating the fault description, replaced parts, and recurrence dates, matching this occasion	Go to the evidence section, bring the old tickets, and do not rely only on saying it broke again
B. A different fault each time	Symptoms differ each time, parts differ, and triggers share no pattern	A timeline showing each direct cause is different	Handle each item separately, ranking first the one that most affects coursework or exams, and do not assume a shared cause
C. Course software or environment trigger	The fault appears only with a particular course program, external device, location, socket, or charger combination, and disappears when that condition is removed	Before-and-after trigger comparison records, see the swap-test table below	Isolate the trigger first, then decide whether it is software, driver, setting, or hardware, and do not replace parts first

The three paths can overlap, for example the same fault recurring only when one program is used. Triage is a starting point, not a diagnosis; the final cause depends on swap tests and inspection by the repair provider. Never turn recurrence directly into a claim that a model is defective: a defect conclusion requires the manufacturer itself to have issued a technical notice or written decision for that batch.

Swap-test table: change only one thing at a time

The swap methods below are working methods proposed in this article, not an industry standard from a cited source; treat them as an investigation starting point, not a conclusion. Back up before any isolation test, and do not run lengthy stress tests on an already unstable machine. If you change the charger, cable, driver, and software all at once, even a disappearing symptom cannot tell you which change mattered.

Swap item	Fault follows the swapped-out item	Fault stays with the original machine or condition	Points to
A known-good original charger or cable in place of a suspected charger	Symptoms disappear under the known-good charger	Symptoms remain	Charger, wattage, or cable clues, versus the machine itself
A different socket, room, or hard flat ventilated surface	Symptoms disappear in the new location	Symptoms are the same everywhere	Power or cooling-environment clues, versus the machine itself
Not opening the suspected course program, using another program for the same work	Symptoms disappear	Symptoms remain	That program, driver, or setting clues, versus hardware clues
A minimal-startup concept, such as Safe Mode or Clean Boot	Symptoms disappear in the minimal environment	Symptoms remain in the minimal environment	Background program or driver clues, versus system or hardware clues

For course software, separate three layers. First, the program itself demands more than the machine provides; the earlier buying baseline is cited as premise only. Second, the fault appeared only after a program, driver, or system update; compare the update timeline. Third, a school system, virtual desktop, or licensing environment issue: if it happens only in the school system, ask school IT support first, and do not treat it as a machine hardware fault for repair. Minimal startup is described as concept and principle only; step details vary by version, and this article does not present a guaranteed step-by-step tutorial. Do not teach readers to open the machine themselves, replace board parts themselves, or handle a swollen battery themselves; a suspected hardware problem should go for inspection.

Recurrence or coincidence: a proposed trigger point

The trigger below is purely a working method proposed in this article, not an industry standard and not a statistic. When the same symptom under the same trigger appears a second time within a short period, it is worth switching from repair-each-time to bring-the-old-tickets-and-timeline mode. That does not prove the previous repair was wrong; it only means the second appearance is worth a careful comparison. Conversely, if symptoms, parts, and triggers differ every time and the dates are spread out, treat them as separate events first. Triggering an investigation does not prove either side wrong; the goal is not to blame, but to avoid sending the machine in again for the same thing.

Before an exam or coursework deadline: protect data first, keep working second, arrange repair last

The order below is this article's suggestion, not any school, manufacturer, or industry official order; adjust it to your own deadline.

Priority	What to do	What counts as done	Common mistake
First: protect data	Copy unfinished coursework, notes, and references to a second location, then open the files on another device to confirm they open, not merely by checking a sync icon	The latest version opens successfully on another device	Trusting only a cloud sync tick, then finding an old or damaged version was synced, or backing up only to another folder on the same machine
Second: keep the deadline covered	Use a borrowed machine, library or computer-room machine, cloud documents, or a phone fallback, so the deadline can still be met	A workable submission route exists, even if imperfect	Insisting on fixing your own machine first, then missing the deadline from both directions
Third: arrange repair	After the deadline is covered, bring the evidence from the next section, arrange repair, and clarify collection arrangements	At drop-off you can state the deadline is already covered by another route, with no need to press for an uncertain repair to meet it	Sending the machine in before protecting data, or hiding the recurrence history so the provider starts from scratch

Borrowed machines and cloud fallbacks have real limits, and this article must not present borrowing a library machine as a complete solution. Loan rules differ across Hong Kong institutions: some loans are in-library only, some must be returned the same day, and some are mainly for temporary departmental use. The correct step is to ask your own library or IT service on the day for the current rules, loan period, whether the machine may leave the building, and whether it has the course software you need. A borrowed machine may not have your specialist software and may not allow installation, and a cloud version may differ from the desktop version; open the file and test the output format on the borrowed machine before submission, and do not assume formatting is unchanged. A pre-deadline check should cover that the file opens on another device, that the file name matches the submission system requirements, and that a submittable version exists even if formatting is not perfect, before dealing with the machine itself. Exam extensions, coursework extensions, and special arrangements differ by school and department; this article has not verified any specific school procedure, promises no extension, and names no deadline or form. It can only say to follow the procedure published by your own department or faculty, and that asking earlier is better. For conditions requiring immediate stop, the earlier article already covered swollen-battery and liquid alerts, cited here as premise only. If a fault comes with an unusual smell, smoke, unusual heat, body deformation, or repeated shutdown immediately after power-on, the deadline-correct step is to stop using the machine and use the second step above, not to power it on repeatedly; repeated power-on attempts may worsen data or hardware condition. That sentence is a conditional statement, not a diagnosis of any specific fault.

Same fault after repair: evidence makes the conversation possible

Evidence matters because checking at the counter and raising a mismatch immediately is far stronger than raising it later. When collecting a machine, check whether the machine condition stated on the repair ticket is accurate, raise any mismatch with the provider immediately, keep the documents, check the machine on the spot, and point out damage not listed on the ticket. Evidence has four parts, and any missing part makes comparison harder. First, a timeline: each incident date, symptoms as actually observed, what you were doing, which program, charger, or external device was in use, and whether there was a drop, liquid contact, or update, stated as facts only. Second, repair tickets: each repair date, the fault description as written by the provider, parts replaced, post-repair test results, and collection date, checked at collection against the stated condition and replaced items. Third, photos or short clips: the screen display, error message, or body condition at the time of symptoms, with date information in the photo; do not publish photos showing the serial number online, and give them only to the repair provider or manufacturer for checking. Fourth, a recurrence comparison: this occasion against the previous ticket description, ticked item by item as same, different, or partly same; that comparison is the starting point for discussion with the provider.

The table below is only a template structure. Every cell is to be filled in by the reader from their own actual records; the example rows show format only and must never be treated as real data.

Record item	First incident	First repair	Recurrence, this occasion
Date, to be filled in by the reader	Fill in the actual date	Fill in the repair-ticket date	Fill in the actual date
Symptoms, actual observation, no inference	Fill in actual observation	Description as written on the repair ticket, copied verbatim	Fill in actual observation
Conditions at the time, program, charger, external device, location	Fill in actual conditions	—	Fill in actual conditions
Repair content, per the repair ticket	—	Fill in verbatim from the repair ticket: replaced parts or handling method	—
Post-repair test, what was done at collection	—	Fill in actual circumstances	—
Same as last time or different	—	—	After item-by-item comparison, fill in: same, different, or partly same

Four questions can be put to the provider as suggestions, not as answers the provider must give. First, the previous ticket stated a fault in these words, copied verbatim, and this occasion shows these symptoms as observed; how do you view whether these are the same fault? Second, what parts were replaced last time, per the ticket, and has that part been checked again this time? Third, after this repair, which test will confirm the same trigger no longer causes the fault, and can we watch it together at collection? Fourth, if the same fault appears again, which documents, old tickets, timeline, or photos, will make comparison fastest? Communication principles are: state observations, not conclusions, saying the machine shuts down every time a certain program opens, not that the previous repair damaged it. Bring the physical items, including any suspected charger, cable, or external device, so the provider can repeat the swap test. Test at collection using the condition that triggered the fault before leaving; a problem found after leaving is much harder to compare. Keep every repair ticket, receipt, and correspondence in original or copy, and do not rely only on verbal promises.

Recurrence has three possible explanations, and none should be assumed before checking. First, the previous repair did not fully resolve the root cause, for example only a surface part was replaced while the trigger remained. Second, the previous repair resolved the old problem, and this is a new problem with similar symptoms, which only the comparison table above can separate. Third, the trigger itself has not changed, for example the same questionable charger or the same triggering program setting is still in use, so the same symptom returns. All three require provider inspection to separate; the timeline alone can only raise a suspicion, not a conclusion.

Warranty and accidental-damage claims: procedure only, no invented store policy

This section covers procedure only and invents no specific store or brand warranty promise, claim outcome, or handling time. Terms can differ by brand, series, and purchase channel; the correct approach is to teach readers how to check the documents they hold, not to give the conclusion for them. Warranty terms follow the documents the reader holds; this article reproduces no warranty-period figures, and readers should rely on their own warranty documents or the result of a serial-number check on the manufacturer website.

Document or information	Why it is needed	Note
Purchase proof, invoice or receipt original	Proves purchase date and purchase channel	Some manufacturers require the invoice to state brand, model name, serial number, and purchase date, with a dealer stamp; an invalid invoice can affect warranty service
Serial number and model name	Used by the manufacturer to identify the product and warranty eligibility	Check the serial number before drop-off, and do not infer from the model name alone
Fault description, symptoms, error messages, when it occurs	Lets the provider or manufacturer triage, rather than only writing that it is broken	Write actual observation, not inference
Photos or clips, if requested	Support the hardware description	Give them only to the other party for checking, and do not publish photos showing the serial number
Extra cover documents, if purchased	For example an extended cover or accidental-damage cover contract or confirmation email	Cover scope also follows the contract wording; do not assume extra cover covers everything
Past repair tickets and timeline, for recurrence cases	Show the history of the same fault	Compare with the evidence table above
Pre-repair backup confirmation	Repair may erase data, and manufacturers generally remind users to back up fully before repair	Backup rules are cited as premise only, without rewriting the details

The list above is a general procedure list, not any brand promise; which items your machine requires depends on the manufacturer or provider requirements at the time. Common refusal or non-acceptance categories are procedure categories only, and the wording must remain that way, with your own terms wording as the authority.

Common non-acceptance category, procedure category only	How to understand it	What to do before drop-off
Document problems	No valid purchase invoice or receipt, altered documents, or document details not matching the product, for example a serial number mismatch	Check the invoice against the serial number before drop-off
Serial-number problems	Serial-number label removed, altered, damaged, or mismatched	Keep a private record of the label, and do not publish it
Accidental damage or misuse	Drops, liquid spills, impacts, cracked screen, leakage, or foreign objects, classed as accidental or misuse categories	Describe events honestly, and do not hide a drop or liquid history
Unauthorised repair or modification	Damage caused by non-authorised repair or modification	Check your own terms wording first
Software or virus problems	Software faults, viruses, or setting problems, generally outside hardware warranty scope, subject to the terms wording	Use swap tests to separate software clues from hardware clues first
Normal wear	For example natural battery ageing, consumable exhaustion, or cosmetic wear, classed as normal wear	State the category only, and write no wear figures or battery-health percentage thresholds

Do not turn any category above into a certainty that you will be refused; the correct wording is that if a case falls in such a category, the manufacturer or provider may decline under the terms, so check your own terms before drop-off. Do not teach readers to hide a drop or liquid history to make a claim; honest description keeps documents consistent and avoids slowing handling, and serious inconsistency can affect later discussion. That sentence is a procedure suggestion, not legal advice, and this article gives no legal advice.

If discussion does not resolve the matter, the procedural route is a consumer-council complaint process. The information to prepare includes complainant details, trader details, transaction details, copies of relevant documents, and the outcome sought. The council role is conciliation, and progress depends on the trader voluntarily cooperating; the council cannot order a trader to apologise or discipline staff. This article must state that limit honestly, must not present a complaint as a guaranteed recovery, must not state any handling time or compensation amount, and must not present the council process as a legal process. Before repair, confirm with the trader the delivery date, warranty arrangement, repair completion date, refund policy, or alternative arrangement; the machine condition on the repair ticket must be accurate, and any mismatch should be raised immediately with documents kept.

Second-hand or family hand-me-down machines: hidden problems that surface mid-semester

For a second-hand or family machine, the hidden problem is often not speed, but three items not verified at handover. First, the battery: at handover it is already an old battery, and current charge level alone is not the check. On Windows, a battery report compares design capacity with current full-charge capacity, and the gap is the wear. On Mac, battery health can be checked in system settings, with cycle count and condition in system information. Cycle count is a design reference, not a countdown; two machines with the same cycle count can differ greatly in health because of heat and charging habits, so the capacity comparison is the main signal. The handover check below is a method proposed in this article, not an industry standard: on handover day, record design capacity, current full-charge capacity, cycle count if shown, whether the base sits flat, and whether the trackpad is raised; only when all items are recorded should term use begin, and any missing item means the handover check is incomplete. Swollen-battery handling follows the earlier article and manufacturer guidance, stated here as one safety line only: stop use, unplug the charger, do not puncture, press, or remove it yourself, and contact the manufacturer or repair shop.

Second, soldered memory and storage: not verified before handover, discovered mid-semester as non-upgradeable. Soldered memory is soldered directly to the board, so the capacity at purchase is the lifetime capacity, and it cannot be upgraded by swapping a memory stick; if there is no extra slot, purchase capacity is the ceiling. Verification means checking the manufacturer repair manual or specification page for that model, not only the seller label, for wording such as soldered, onboard, or no memory slots, or checking slot count and occupancy with a system tool, or checking with a manufacturer upgrade tool. Some machines mix one soldered side with one slot, so the maximum supported total must be verified; do not assume a slot means any desired capacity can be added. Storage follows the same logic: do not trust a capacity figure alone, and verify whether it is a solid-state drive or an older mechanical drive, whether it is replaceable, and whether the slot is already occupied. The three handover questions are: is memory soldered or slotted, what is the maximum supported total, and is storage soldered or replaceable; if any question is unanswered, do not use later upgrade as the reason to accept the machine. The earlier article covered how much memory a new machine needs; this article covers only how soldered structure blocks that upgrade route for a hand-me-down, and does not rewrite the specification baseline table.

Third, old-system support ending: the largest hidden cost of an old hand-me-down is not speed, but support. Windows 10 support ended on 14 October 2025, after which there are no more monthly security updates, feature updates, or standard technical support. Windows 11 minimum requirements include a trusted platform module, firmware supporting Secure Boot, and a compatible processor list. A manufacturer computer-health check tool can verify upgrade eligibility. For Mac, the manufacturer defines categories by time since discontinuation, covering whether hardware repair remains available subject to parts supply; a second-hand Mac should be checked against the manufacturer official list for that model, not judged by year or appearance alone. End of support does not mean the machine stops working immediately; the point is risk and school-software compatibility, not a scare claim that replacement is immediately required, and no upgrade success rate or time can be promised.

Handover check item	How to verify	If not verified
Battery health comparison	Design capacity versus current full-charge capacity, whether the base sits flat, whether the trackpad is raised	Treat the handover check as incomplete until all items are recorded
Memory structure	Manufacturer manual or specification page wording on soldered, onboard, or no slots, plus system-tool slot occupancy	Do not use a later upgrade as the handover reason
Storage structure	Whether it is a solid-state drive, whether it is replaceable, whether the slot is already occupied	Do not trust a capacity figure alone
System support status	Operating-system version and support status, upgrade-eligibility check result, Mac official-list status	Check first whether school software still supports that system version
Previous-owner usage history	Body impact marks, loose hinges, any individual key failure, every port tested one by one, unusual fan noise under light load	History invisible on the surface can surface mid-semester
Previous-owner accounts and authorisation	Whether the previous owner has signed out, removed device binding, and handed over encryption recovery information if encrypted	An uncleared account can lock reinstallation or repair mid-semester
Whether the charger is original or to specification	Compare the charger label output with the original requirement for that model, recording both figures	Family hand-me-downs often come with a substitute charger, so check the label before any swap test

Family hand-me-down items above are all working-check proposals in this article, not statistics and not industry standards. Previous-owner history is unknown: whether the machine was kept plugged in long term, kept hot, dropped, or exposed to liquid may not be visible. Previous-owner accounts and authorisation must be cleared at handover: sign out, remove device binding, and hand over encryption recovery information, otherwise reinstallation or repair mid-semester can be locked. A charger that is not original or not to specification is common when a family charger is lost and replaced casually; see the swap-test section for label comparison and swap testing.

Replace mid-semester or endure to the end of term: a decision framework based on actual symptoms

The framework below is a working method proposed in this article, not an industry standard, and not a rewrite of the earlier fifty-percent rule. The earlier fifty-percent rule is cited in this article in one place only, without expansion and without reproducing the earlier per-situation leaning table. The decision looks only at three classes of actual symptoms, not at machine age alone. First, safety and data red lines: swollen battery, a body too hot to touch, unusual sounds from the storage device or frequent read failures, or data damaged or disappearing without reason; if any item appears, the framework suggests stopping use and sending the machine for inspection, not enduring to the end of term. Second, coursework interruption frequency: whether the same symptom recurs during term, whether it appears at coursework submission, exams, or class presentations, and whether each interruption requires rework or loses progress; the focus is recurrence and critical moments, not a single occasional event. Third, whether an alternative is immediately available: library loan, another usable computer, a school computer room, or complete cloud files; an alternative changes the cost of enduring, but never changes the safety judgement in the first class. The hard rule is that no repair completion time can be promised, no few-days return can be promised, and replacement cannot be presented as solving every problem; every time statement can only say that the decision follows a written quotation after inspection and the actual repair circumstances.

The table below is only a template structure. The fill-in wording inside is not data; readers must fill it in from their own machine records and must not treat the template as a real case or statistic.

Field	How to fill it in
Symptoms, actual observation, no inference	Write what was seen, heard, or happened, not a suspected board fault
First appearance date	Fill in from your own records
Occurrences during term	Fill in from your own records, do not estimate
Whether it appeared at a critical moment, submission, exam, presentation	Yes or no, fill in from actual events
Loss per interruption, how much rework, which files were lost	Fill in from actual events
Separation steps already tried	Record each step, not only that everything was tried
Safety or data red line	Present or absent, fill in from actual events
Alternative, loan, another machine, computer room	Present or absent, and whether loan rules have been asked about
Leaning, method-proposal output	Fill in from the framework judgement, see the three postures below

Posture	Applicable conditions, method proposal	Next step
Stop use and send for inspection	Any safety or data red line appears	Stop use, back up if still safe to do so, send for inspection, and start the alternative at the same time
Endure to the end of term, with monitoring	No red line, symptoms occasional, not at critical moments, an alternative exists, and a symptom log is kept	Keep using it, but review the record table weekly; if symptoms move into a red line or appear at a critical moment, switch to the first row immediately
Replace mid-semester, or change the main machine	No red line, but symptoms recur and have appeared at critical moments, or repair cost already leans to replacement under the earlier fifty-percent rule, or support has ended plus school software incompatibility	Decide on the basis of a written quotation after inspection, and complete the pre-repair self-protection checklist before changing machines

The three postures are not an average score: a red line overrides all other conditions and goes directly to the first row. Hidden costs of changing machines are listed as items only, with no amounts: moving data, reinstalling school software, re-signing in and re-authorising, adapting to a new keyboard, screen, or system, and handling old-machine data; amounts follow a written quotation after inspection, or actual school or manufacturer charges.

Before sending for repair: verified backup, signed-out accounts item by item, ticket fields checked item by item

Pre-repair backup checks list checkpoints only and do not rewrite the earlier backup details. Repair may involve replacing storage parts, and the provider cannot guarantee data recovery, so personal files should be backed up to an external drive or cloud before repair. Sync is not backup: a sync service mirrors wrongly deleted or damaged files to the cloud as well, cited from the earlier article in one sentence. The reader-filled pre-repair backup checklist is: whether coursework, thesis, or project files open from a second location, not merely that they were uploaded; whether desktop, downloads, or non-default folders contain missed files; whether browser bookmarks, school-system login information, and software licence information are saved elsewhere; whether encryption recovery information, if any, is saved in a second location; and a restore test, opening one sampled file on another device to confirm it can be retrieved.

For account sign-out and authorisation removal, signing out is not deleting files. Signing out or removing authorisation only removes account access on that device; the files themselves remain on the drive, and secure erasure that truly prevents recovery is a sale or disposal procedure, not a pre-repair procedure. The pre-repair approach is to sign out of email, social, and cloud accounts, remove authorisation for licensed software where applicable, temporarily disable security features that would block technician testing, such as encryption, BIOS passwords, or fingerprint or face sign-in, and record what was disabled so it can be re-enabled after repair. The sign-out list is ticked item by item: school email, personal email, cloud drive, browser sync, messaging software, paid software licences, and school-system automatic sign-in; each item is marked signed out or not applicable, not merely handled. A special reminder is that if a school account has device binding or two-factor verification, confirm on another device that the school system can still be signed into before repair, otherwise even a borrowed machine cannot be signed into during repair. No guarantee can be written that a repair shop will not look at your files; the correct wording is to reduce sensitive data left on the machine, with risk controlled by the owner.

Repair-ticket field	Why it must be written	If it is not written
Drop-off date	Starting point for the symptom log and repair timeline	Ask for it to be added on the spot
Model and serial number	Manufacturer checks and warranty status must be checked per serial number, not inferred from the model	Check the serial number on the spot
Symptoms, actual observation	Technicians need observations, not inferences	Add them using the four-column swap-test wording
Separation steps and swap-test results already tried	Avoid repeating tried steps and shorten inspection time	Bring the decision record table
Items left with the machine, charger, cable, other accessories	Without a suspected charger, a swap test cannot be done	State whether each item was handed over
Quotation method	Always a written quotation after inspection; a verbal quotation needs written confirmation	Do not authorise repair before a written quotation exists
Expected contact method and review date	Avoid open-ended waiting for notification	Agree the next update date on the spot
Data-handling agreement	Whether repair involves reinstallation, storage replacement, or data erasure	State that reinstallation or storage replacement requires contacting the owner first
Collection checks	Test at collection whether symptoms recur, and check for new body damage	Test item by item at collection, not after returning to the dormitory

A final one-page pre-repair checklist, all proposed methods in this article, not industry standards: backup verified, with a sampled file opened on another device; account sign-out list ticked item by item; symptom record table brought; suspected charger or cable, if any, brought as well; repair-ticket fields checked item by item; and an alternative confirmed as usable, not asked about only on drop-off day.

Pricing notes

Causes of mid-semester recurrence vary by symptom, trigger, and scope, and all work follows a written quotation after inspection. Confirmed routine prices are:

Item	Price
Battery	HK$580 up
Screen	HK$1,280 up
Main board chip-level	HK$880 up
Keyboard	HK$480 up
Recurrence investigation, warranty-claim document checking, and other repairs	Quoted in writing after inspection

Whether or not the fault has already recurred, bring the machine for a professional diagnostic, so the technician can exclude each trigger using the triage and swap-test methods above before assessing. More routine prices are on the pricing page. Shop: 沙田石門達利廣場 1209 室 | Tel +852 2186 8010 | WhatsApp +852 6558 6806 | Hours 12:00–19:00.

FAQ

Q1: The machine broke again after repair. Does that mean the previous repair was bad?
A1: No such conclusion can be drawn. Use the evidence table to compare symptoms, parts, and triggers, and separate three explanations: the previous repair did not fully resolve the root cause, the previous repair resolved the old problem but this is a new problem, or the trigger itself has not changed. Bring the old tickets, timeline, and photos for comparison, and do not turn it into an accusation against any provider, and do not promise any compensation.

Q2: The machine failed again the day before an exam or submission. Should I repair it first or submit first?
A2: Follow this article's suggested order: protect data, keep the deadline covered, then arrange repair. First copy files to a second location and confirm they open on another device, then use a borrowed machine, computer room, or cloud version to cover the deadline, and only then bring the evidence for repair. Loan rules differ by school and must be asked about on the day at your own school; this article promises no extension and names no school extension procedure.

Q3: How do I tell a course-program problem from a hardware problem?
A3: Use swap-test logic: change the condition, try a minimal startup, and change only one thing at a time. Check whether symptoms disappear after closing the suspected program, whether they appear in a minimal environment for the same operation, and whether they appear with a similar program for the same work; if they occur only in the school system, ask school IT support first. This covers separation methods only, and names no program version or driver number as the cause.

Q4: For a repair under warranty, what should I bring so the trip is not wasted?
A4: Follow the warranty-claim document list: purchase proof, serial number, fault description, extra-cover documents if any, and old repair tickets with a timeline, with backup confirmed by opening files on another device before drop-off. Common refusal categories are procedure categories only, subject to your own terms wording; this article writes no store or brand policy, no warranty-period figures, and promises no claim outcome.