Siemens Healthineers ACUSON Juniper

System Freeze, Slow Boot, Or Application Crash

On this page

Asset Type

Ultrasound System

Manufacturer

Siemens Healthineers

Model

ACUSON Juniper

What This Guide Helps With

Troubleshooting Juniper freezing, slow startup, software crashes, boot delays, or intermittent application lockups before repair escalation.

Step-by-Step Troubleshooting

Ensure Patient Safety First

Confirm the ACUSON Juniper is not actively being used on a patient.

If the system freezes during an exam, have clinical staff stop scanning, protect the patient, and move to another ultrasound system if imaging is still needed.

Expected outcome: Patient care is not delayed or continued on an unstable imaging system.

Confirm the Exact Symptom

Ask the sonographer or clinical user what happened and when.

Determine whether the issue involves:

Expected outcome: The issue is separated into startup, application, user interface, imaging, storage, or network-related behavior.

Check for an Active Patient Exam or Unsaved Study

Before powering off or restarting, confirm whether an exam is open and whether images or measurements may be unsaved.

If possible, allow clinical staff to save or document the exam status before rebooting.

Expected outcome: Patient study data is protected before troubleshooting continues.

Perform a Controlled Restart if Safe

If the system is frozen and no patient is connected, attempt a normal shutdown from the user interface.

If the system does not respond, follow site-approved hard shutdown procedures only after confirming no active patient use or pending critical data.

Expected outcome: The system restarts cleanly and returns to normal operation. If this resolves the issue, document the reboot and monitor for recurrence.

Verify AC Power and Power Cord Connection

Check that the AC power cord is fully seated at the wall, power brick if applicable, and system connection.

Confirm the outlet is hospital-grade, powered, and not controlled by a switched wall outlet.

Expected outcome: The system receives stable AC power. If power was loose or unstable and correcting it resolves the freeze or boot issue, stop.

Check Battery or Internal Power Status if Applicable

If the system was running on battery or had recently been unplugged, check battery charge status and whether the issue occurred during low battery operation.

Low or unstable power can cause slow booting, unexpected shutdown behavior, or system instability.

Expected outcome: The issue is not being caused by low battery or unstable power transfer.

Remove Nonessential External Accessories

Disconnect nonessential USB drives, external keyboards, printers, barcode scanners, footswitches, and other accessories.

Restart the system with only required probes and power connected.

Expected outcome: A faulty or incompatible external accessory is ruled out. If the system boots normally after removing an accessory, test accessories one at a time to identify the cause.

Check Probe Connection and Probe Behavior

Inspect the connected transducer for damaged cable jacket, bent connector pins, fluid contamination, or loose seating.

If the crash occurs when a specific probe is selected, disconnect that probe and test with a known-good compatible probe.

Expected outcome: The issue is not being triggered by a damaged or problematic transducer.

Check the Control Panel and Touchscreen Response

Confirm whether only the imaging application is frozen or whether the entire user interface is unresponsive.

Check touchscreen, trackball, keyboard, rotary controls, and soft keys.

Expected outcome: The problem is narrowed to a software lockup, input device issue, or full system hang.

Check System Storage and Exam Queue Status

Ask staff whether the system has a large number of stored studies, failed transfers, or pending exams.

Review available storage status if accessible from the system menus.

Full storage, large unsent queues, or repeated failed transfers may slow booting, shutdown, or application performance.

Expected outcome: Storage or workflow backlog is identified before assuming a computer hardware failure.

Check Network Connection

If the freeze or delay occurs during study send, worklist query, PACS transfer, or shutdown, disconnect the network cable or disable wireless if permitted by site policy and test local system operation.

Confirm with IT or PACS support whether the network, DICOM destination, or worklist server is available.

Expected outcome: The issue is separated between local system performance and network-related delay.

Review Error Messages and Event Details

Record any displayed error code, application message, warning, or abnormal boot screen.

Note whether the system restarts by itself, shows a Windows or application-level error, or remains stuck at a Siemens startup screen.

Expected outcome: Specific failure information is captured for service evaluation.

Check for Recent Changes

Ask whether anything changed before the problem started, including:

Expected outcome: A recent external or configuration change is identified as a possible cause.

Allow the System to Boot Fully Before Judging Performance

If the complaint is slow boot, time the startup from power-on to usable imaging screen.

Compare the behavior to staff reports and any known normal boot behavior for that location.

Expected outcome: The issue is confirmed as an abnormal boot delay rather than normal startup time.

Check Ventilation and Overheating Signs

Inspect the air vents, fan area, rear panel, and cart area for blocked airflow, dust buildup, unusual heat, or fan noise.

Do not open the system or perform internal cleaning beyond approved external cleaning.

Expected outcome: External airflow restriction or overheating concern is identified.

Perform a Functional Check After Reboot

Once the system boots, confirm basic operation:

Expected outcome: The system is either returned to service after passing functional checks or held for further evaluation.

Monitor for Recurrence

If the system appears normal after restart, ask staff to report whether the issue returns with the same probe, same exam type, same network workflow, or after a certain amount of use.

Expected outcome: Intermittent faults are tracked with enough detail to support repair escalation if needed.

If the Problem Persists

If the ACUSON Juniper continues to freeze, boot slowly, crash applications, or lock up after power, accessory, probe, storage, and network checks are complete, the likely cause may be internal computer hardware, system software corruption, storage drive failure, overheating, or another service-level fault.

The device should be:

Knowing when to stop is proper troubleshooting. Repeated application crashes or freezes should not be cleared repeatedly without identifying the cause, especially if patient exams or stored images may be affected.

Clinical Use Tip

Do not troubleshoot software freezes or reboot behavior while scanning an active patient unless patient safety requires stopping immediately. Move the patient to another available ultrasound system first, then troubleshoot the ACUSON Juniper when it is safe and patient data is protected.

Work Order Documentation (CCR Method)

CCR = Complaint, Cause, Resolution

Complaint

What was reported by the clinical staff.

Example:
"Sonographer reported the ACUSON Juniper froze during exam setup and was slow to reboot after restart."

Cause

What was observed during troubleshooting.

Example:
"Verified no active patient was connected, checked AC power, removed USB accessory, inspected probe connection, and found the system continued to intermittently freeze after startup."

Resolution

What action was taken.

Example:
"Removed the ultrasound system from service, labeled it Out of Service, documented boot behavior and error details, and escalated for bench evaluation or vendor service."

Helpful Details to Include (If Known)

Final Thought

System freezes and application crashes should be handled with patient safety and data protection first. Clinical Engineering should rule out power, accessories, probes, storage, and network issues before suspecting internal failure. If instability continues, removing the system from service and documenting the troubleshooting clearly protects both patients and the repair process.

That is successful troubleshooting.

Related Guides

Was this guide helpful?

Don't see a guide you need?

Suggest a Guide