Unstable shutdown due to high GPU fan speeds.
Unstable shutdown due to high GPU fan speeds.
System Details: Motherboard model - GIGABYTE X570 AORUS XTREME AMD CPU - AMD Ryzen 9 5950X (Ryzen 9 5000 Series Vermeer Zen 3, 16 cores, 3.4 GHz, AM4, 105W, no integrated graphics)
Desktop Graphics - GIGABYTE AORUS GeForce RTX 4090, 24GB GDDR6X PCIe 4.0
Power Supply - CORSAIR AX1600
RAM - CORSAIR Dominator Platinum RGB, 64GB (2 x 32GB), DDR4 3600
I’m experiencing random black screen crashes. During these events, all three display outputs disconnect and the GPU fans reach maximum speed. I still hear audio—game sounds or background videos. This has happened only three times, the last one was a few weeks ago while I paused a game, and then twice this evening within five minutes.
My previous setup was a Ryzen 7 1800X with a GIGABYTE AORUS RTX 2080 Ti (11GB, factory AIO water cooling). About a year ago, it started showing the same problems with identical symptoms.
Anyone know what might be causing this and how to resolve it? Would you like a tool that logs crashes so you can review what triggered the failure? For example, after rebooting and opening a crash logger, it should show details like GPU or CPU overheating, motherboard faults, etc. If you have any leads, it would be really helpful!
Please read this article on what information we need before you post... hence why we're asking more questions: Is this a fresh Windows install? Or are you re-using old Windows from your last computer? Please list your hard drives/SSDs/NVMe drivers If your UEFI (BIOS) version is not F36 or F37F please update to F36 (F37f is a security update only and will hurt performance... it's up to you if you want the added security) Did you install the latest chipset drivers from August 2023? Have you cleared the CMOS ? Yes, there is a program that logs what happens. It's called Event Viewer and is part of Windows. The System Log is what you would want to look at: Spoiler If you've done all those things and it doesn't fix anything, let's check all the cores on your 5950x for stability: Download CoreCycler from Github (latest version is fine) Extract the zip file to somewhere on your computer Open config.ini Delete everything in config.ini [ Ctrl + A >> Delete key] Copy this config.ini and paste it into your config.ini Spoiler # General settings [General] # The program to perform the actual stress test # The following programs are available: # - PRIME95 # - AIDA64 # - YCRUNCHER # You can change the test mode for each program in the relavant [sections] below. # Note: For AIDA64, you need to manually download and extract the portable ENGINEER version and put it # in the /test_programs/aida64/ folder # Note: AIDA64 is somewhat sketchy as well # Default: PRIME95 stressTestProgram = YCRUNCHER # Set the runtime per core # You can define a specific runtime per core, by entering a numeric value in seconds, # or use 'h' for hours, 'm' for minutes and 's' for seconds # Examples: 360 = 360 seconds # 1h4m = 1 hour, 4 minutes # 1.5m = 1.5 minutes = 90 seconds # # Automatic runtime: # You can also set it to "auto", in which case it will perform one full run of all the FFT sizes in the selected # Prime95 preset for each core, and when that is finished, it continues to the next core and starts again # For Aida64 and y-Cruncher, the "auto" setting will default to 10 Minutes per core # # Below are some examples of the runtime for one iteration for the various tests on my 5900X with one thread # The first iteration is also usually the fastest one # Selecting two threads usually takes *much* longer than one thread for one iteration in Prime95 # - Prime95 "Smallest": 4K to 21K - [SSE] ~3-4 Minutes <|> [AVX] ~8-9 Minutes <|> [AVX2] ~8-10 Minutes # - Prime95 "Small": 36K to 248K - [SSE] ~4-6 Minutes <|> [AVX] ~14-19 Minutes <|> [AVX2] ~14-19 Minutes # - Prime95 "Large": 426K to 8192K - [SSE] ~18-22 Minutes <|> [AVX] ~37-44 Minutes <|> [AVX2] ~38-51 Minutes # - Prime95 "Huge": 8960K to MAX - [SSE] ~13-19 Minutes <|> [AVX] ~27-40 Minutes <|> [AVX2] ~33-51 Minutes # - Prime95 "All": 4K to MAX - [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes # - Prime95 "Moderate": 1344K to 4096K - [SSE] ~7-15 Minutes <|> [AVX] ~17-30 Minutes <|> [AVX2] ~17-33 Minutes # - Prime95 "Heavy": 4K to 1344K - [SSE] ~15-28 Minutes <|> [AVX] ~43-68 Minutes <|> [AVX2] ~47-73 Minutes # - Prime95 "HeavyShort": 4K to 160K - [SSE] ~6-8 Minutes <|> [AVX] ~22-24 Minutes <|> [AVX2] ~23-25 Minutes # - y-Cruncher: Depends on the number of selected tests and the duration per test # Default: 6m runtimePerCore = auto # Periodically suspend the stress test program # This can simulate load changes / switches to idle and back # Setting this to 1 will periodically suspend the stress test program, wait for a bit, and then resume it # You should see the CPU load and clock speed drop significantly while the program is suspended and rise back up again # Note: This will increase the runtime of the various stress tests as seen in the "runtimePerCore" setting by roughly 10% # Default: 1 suspendPeriodically = 1 # The test order of the cores # Available modes: # Default: On CPUs with more than 8 physical cores: 'Alternate'. Otherwise 'Random' # Alternate: Alternate between the 1st core on CCD1, then 1st on CCD2, then 2nd on CCD1, then 2nd on CCD2, etc. # This should distribute the heat more evenly and possibly allow for higher clocks on CPUs with 2 CCDs # Random: A random order # Sequential: Cycle through the cores in numerical order # # You can also define your own testing order by entering a list of comma separated values. # The list will be processed as provided, which means you can test the same core multiple times per iteration. # Do note however that the "coresToIgnore" setting still takes precedence over any core listed here. # The enumeration of cores starts with 0 # Example: 5, 4, 0, 5, 5, 7, 2 # # Default: Default coreTestOrder = Default # Skip a core that has thrown an error in the following iterations # If set to 0, this will test a core in the next iterations even if has thrown an error before # Default: 1 skipCoreOnError = 1 # Stop the whole testing process if an error occurred # If set to 0 (default), the stress test programm will be restarted when an error # occurs and the core that caused the error will be skipped in the next iteration # Default: 0 stopOnError = 0 # The number of threads to use for testing # You can only choose between 1 and 2 # If Hyperthreading / SMT is disabled, this will automatically be set to 1 # Currently there's no automatic way to determine which core has thrown an error # Setting this to 1 causes higher boost clock speed (due to less heat) # Default: 1 # Maximum: 2 numberOfThreads = 1 # Use only one thread for load generation, but assign the affinity to both virtual (logical) cores # This way the Windows Scheduler should bounce the load back and forth between the two virtual cores # This may lead to additional stress situation otherwise not possible # This setting has no effect if Hyperthreading / SMT is disabled or if numberOfThreads = 2 # Default: 0 assignBothVirtualCoresForSingleThread = 1 # The max number of iterations # High values are basically unlimited (good for testing over night) # Default: 10000 maxIterations = 10000 # Ignore certain cores # Comma separated list of cores that will not be tested # The enumeration of cores starts with 0 # Example: coresToIgnore = 0, 1, 2 # Default: (empty) coresToIgnore = # Restart the stress test process when a new core is selected # This means each core will perform the same sequence of tests during the stress test # Note: The monitor doesn't seem to turn off when this setting is enabled # # Important note: # One disadvantage of this setting is that it has the potential to limit the amount of tests that the stress test program # can run. # In Prime95 for example, each FFT size will run for roughly 1 minute (except for very small ones), so if you want to make # sure that Prime95 runs all of the available FFT sizes for a setting, you'll have to extend the "runtimePerCore" setting # from the default value to something higher. # For example the "Huge"/SSE preset has 19 FFT entries, and tests on my 5900X showed that it roughly takes 13-19 Minutes # until all FFT sizes have been tested. The "Large"/SSE seems to take between 18 and 22 Minutes. # I've included the measured times in the comment for the "runtimePerCore" setting above. # # If this setting is disabled, there's a relatively high chance that each core will eventually pass through all of the # FFT sizes since Prime95 doesn't stop between the cores and so it evens out after time. # # Default: 0 restartTestProgramForEachCore = 0 # Set a delay between the cores # If the "restartTestProgramForEachCore" flag is set, this setting will define the amount of seconds between the end of the # run of one core and the start of another # If "restartTestProgramForEachCore" is 0, this setting has no effect # Default: 15 delayBetweenCores = 15 # Prime95 specific settings [Prime95] # The test modes for Prime95 # SSE: lightest load on the processor, lowest temperatures, highest boost clock # AVX: medium load on the processor, medium temperatures, medium boost clock # AVX2: heavy load on the processor, highest temperatures, lowest boost clock # AVX512: only available for certain CPUs (Ryzen 7000, some Intel Alder Lake, etc) # CUSTOM: you can define your own settings for Prime. See the "customs" section further below # Default: SSE mode = SSE # The FFT size preset to test for Prime95 # These are basically the presets as present in Prime95, plus an additional few # Note: If "mode" is set to "CUSTOM", this setting will be ignored # Smallest: 4K to 21K - Prime95 preset text: "tests L1/L2 caches, high power/heat/CPU stress" # Small: 36K to 248K - Prime95 preset text: "tests L1/L2/L3 caches, maximum power/heat/CPU stress" # Large: 426K to 8192K - Prime95 preset text: "stresses memory controller and RAM" (although dedicated memory stress testing is disabled here by default!) # Huge: 8960K to MAX - anything beginning at 8960K up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512) # All: 4K to MAX - 4K to up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512) # Moderate: 1344K to 4096K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000" # Heavy: 4K to 1344K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000" # HeavyShort: 4K to 160K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000" # # You can also define you own range by entering two FFT sizes joined by a hyphen, e.g 36-1344 # # Default: Huge FFTSize = Huge # Aida64 specific settings [Aida64] # The test modes for Aida64 # Note: "RAM" consumes basically all of the available memory and makes the computer pretty slow # You can change the amount of RAM being used / tested with the "maxMempory" setting below # CACHE: Starts Aida64 with the "Cache" stress test # CPU: Starts Aida64 with the "CPU" stress test # FPU: Starts Aida64 with the "FPU" stress test # RAM: Starts Aida64 with the "Memory" stress test # You can also combine multiple stress tests like so: CACHE,CPU,FPU # Default: CACHE mode = CACHE # Use AVX for Aida64 # This enables or disables the usage of AVX instructions during Aida64's stress tests # Default: 0 useAVX = 0 # The maximum memory allocation for Aida64 # Sets the maximum memory usage during the "RAM" stress test in percent # Note: Setting this too high can cause your Windows to slow down to a crawl! # Default: 90 maxMemory = 90 # y-Cruncher specific settings [yCruncher] # The test modes for y-Cruncher # See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation # "00-x86" - 86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...) # "04-P4P" - SSE, SSE2, SSE3 # "05-A64 ~ Kasumi" - x64, SSE, SSE2, SSE3 # "08-NHM ~ Ushio" - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1 # "11-SNB ~ Hina" - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX # "13-HSW ~ Airi" - x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 # "14-BDW ~ Kurumi" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 # "17-ZN1 ~ Yukina" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 # "19-ZN2 ~ Kagari" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 # "20-ZN3 ~ Yuzuki" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2 # # The following settings are available as well, but they seem to be intended for Intel CPUs and don't run on Ryzen 3000/5000 CPUs # "11-BD1 ~ Miyu" - x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, ABM, FMA4, XOP # "17-SKX ~ Kotori" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ) # "18-CNL ~ Shinoa" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI) # The follwing setting is intended for Ryzen 7000 CPUs and doesn't run on Ryzen 3000/5000 CPUs # "22-ZN4 ~ Kizuna" - x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI/GFNI) # # "00-x86" should produce the highest boost clock on most tests # "19-ZN2 ~ Kagari" is optimized for Zen 2/3 (Ryzen 3000/5000), but produces more heat and a lower boost clock on most tests # "22-ZN4 ~ Kizuna" is optimized for Zen 4 (Ryzen 7000) and uses AVX-512 instructions (it will crash if no AVX-512 is supported on your CPU) # Default: 00-x86 mode = 19-ZN2 ~ Kagari # Set the test algorithms to run for y-Cruncher # y-Crunchers offers various different "tests" that it can run, here you can select which ones # Tag - Test Name Component CPU------Mem # BKT - Basecase + Karatsuba Scalar Integer -|-------- # BBP - BBP Digit Extraction Floating-Point |--------- depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # SFT - Small In-Cache FFT Floating-Point -|-------- depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # FFT - Fast Fourier Transform Floating-Point ---------| depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # N32 - Classic NTT (32-bit) Scalar Integer -----|---- depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # N64 - Classic NTT (64-bit) Scalar Integer ---|------ depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # HNT - Hybrid NTT Mixed Workload -----|---- # VST - Vector Transform Floating-Point ------|--- depending on the selected mode uses SSE, AVX, AVX2 or AVX512 # C17 - Code 17 Experiment AVX2/512 Mixed ---|------ depending on the selected mode uses AVX2 or AVX512 # # Important: # "C17" (Code 17 Experiment) will only work with a AVX2 and AVX512 workload (so with mode "13-HSW ~ Airi" and above) # # Use a comma separated list # Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST # Set the duration in seconds for each test in y-Cruncher # The duration for each individual test selected above in the "tests" setting # Note: not the total runtime # # Default: 60 testDuration = 60 # Memory allocation for y-Cruncher # This allows you to customize the allocated memory for y-Cruncher # Set the value in bytes (e.g. 1 GiB = 1073741824) # The default value uses 12.8 MiB for one resp. 25.3 MiB for two threads # # Default: Default memory = Default # Enable or disable the custom logging wrapper for y-Cruncher # We are using the helpers/WriteConsoleToWriteFileWrapper.exe executable to capture the output of y-Cruncher and write it to a file # It is using the Microsoft Detours C++ library to do so # Here you can disable this behaviour and revert back to the original y-Cruncher execution # # Default: 1 enableYCruncherLoggingWrapper = 1 # Log specific settings [Logging] # The name of the log file # The "mode" parameter, the selected stress test program and test mode, as well as the start date & time will be # added to the name, with a .log file ending # Default: CoreCycler name = CoreCycler # Set the log level # 0: Do not log or display additional information # 1: Write additional information to the log file (verbose) # 2: Write even more information to the log file (debug) # 3: Also display the verbose messages in the terminal # 4: Also display the debug messages in the terminal # Default: 2 logLevel = 2 # Custom settings for Prime95 [Custom] # This needs to be set to 1 for AVX mode # (and also if you want to set AVX2 below) CpuSupportsAVX = 1 # This needs to be set to 1 for AVX2 mode CpuSupportsAVX2 = 1 # This also needs to be set to 1 for AVX2 mode on Ryzen CpuSupportsFMA3 = 1 # This needs to be set to 1 for AVX512 mode CpuSupportsAVX512 = 0 # The minimum FFT size to test # Value for "Smallest FFT": 4 # Value for "Small FFT": 36 # Value for "Large FFT": 426 MinTortureFFT = 4 # The maximum FFT size to test # Value for "Smallest FFT": 21 # Value for "Small FFT": 248 # Value for "Large FFT": 8192 MaxTortureFFT = 8192 # The amount of memory to use in MB # 0 = In-Place TortureMem = 0 # The max amount of minutes for each FFT size during the stress test # Note: It may be much less than one minute, basically it seems to be "one run or one minute, whichever is less" TortureTime = 1 # Debug settings that shouldn't need to be changed # Only change them if you know what you're doing and there's a problem you're trying to identify [Debug] # Debug setting to disable the periodic CPU utilization check # # Important: # Normally you should not need to set this, as it is the only way to determine for certain test programs (like y-Cruncher) # if the stress test is still running or if there has been an error. # However on some systems this seems to report incorrect values, which causes the script to throw an error despite # the stress test program still running fine, so here is a way to disable this behavior. # # Be aware that you will have no idea which core has thrown an error if "disableCpuUtilizationCheck" is set to 1 # and "restartTestProgramForEachCore" is set to 0. # y-Cruncher is always initialized with logical core 2 (and 3 for two threads), and since CoreCycler has no way of knowing # that there has been an error with "disableCpuUtilizationCheck = 1", it will just keep on running, while y-Cruncher will # always display logical core 2 (and 3) as the one having thrown the error. # # Note: The check for the CPU utilization uses the Windows Performance Counters, which can be corrupted for unknown # reasons. Please see the readme.txt and the /tools/enable_performance_counter.bat file for a possible way # to fix these issues. There's no guarantee that it works though. # # Default: 0 disableCpuUtilizationCheck = 0 # Debug setting to enable querying for the CPU frequency # # This setting enables checking the CPU frequency # Currently it doesn't really serve any purpose. The retrieved CPU frequency is not accurate enough (e.g. compared to HWiNFO), # and its output is limited to the "verbose" channel. # According to some reports, enabling it can result in incorrect CPU utilization readings, so be aware of this when you enable # this setting. # # Default: 0 enableCpuFrequencyCheck = 0 # Debug setting to control the interval in seconds for the CPU utilization check and the "suspendPeriodically" functionality # # Don't set this too low, it will spam the log file and can produce unnecessary CPU load. # It would also increase the time when the stress test program is suspended # I'd consider 10 to be the minimum reasonable value (which is also the default) # # If 0, will disable this functionality # This basically would mean "disableCpuUtilizationCheck = 1" and "suspendPeriodically = 0" # Not entirely though, as the last check before changing a core is not affected # # Default: 10 tickInterval = 10 # Debug setting to delay the first error check for each core # # With this setting you can define a wait time before the first error check happens for each core # Some systems may need longer to initialize the stress test program, which can result in an incorrect CPU utilization detection, # so setting this value might resolve this issue # Don't set this value too high in relation to your "runTimePerCore" though # # Default: 0 delayFirstErrorCheck = 0 # Debug setting to set the priority of the stress test program # # The default priority is set to "High" so that other applications don't interfere with the testing # It can cause the computer to behave sluggish though. Setting a lower priority can fix this # # Note: "RealTime" probably won't work and you shouldn't set this anway, as the computer won't be responsive anymore # # Possible values: # Idle # BelowNormal # Normal # AboveNormal # High # RealTime # # Default: High stressTestProgramPriority = High # Debug setting to display the stress test program window in the foreground # # If enabled, will display the window of the stress test program in the foreground, stealing focus # If disabled (default), the window will either be minimized to the tray (Prime95) or be moveed to the background, # without stealing focus of the currently opened window (y-Cruncher) # # Default: 0 stressTestProgramWindowToForeground = 0 # Debug setting to control the amount of milliseconds the stress test program would be suspended # # Default: 1000 suspensionTime = 1000 Save the file Last chance... did you clear the CMOS from #6 above? If you didn't, this may not work correctly because your RAM may be overclocked. Double-click Run CoreCycler.bat Continue to use your computer (you can even game) and shouldn't notice much while it's running unless you're doing intense all-core workloads You can look at the window while it's running, and annotate any errors (they will be core specific). Once it says Iteration 2 you can stop it. (This means it's tested all 16 cores.) If for some reason it crashes the computer that also tells us something
This is a classic sign of a gpu hardware failure. Gigabyte 3080s were notorious for this behavior. It happens when the pcb cracks by the pcie connector tab - there are power traces right by the tab. I would take the card out and check that area very carefully.
Updated system details meet Forum guidelines. Apologies, I rushed to post before it failed again. Windows 11 Pro 64bit Version 22H2, GIGABYTE X570 AORUS XTREME AMD BIOS v37f, AMD Ryzen 9 5950X (no overclocking), CORSAIR Dominator Platinum RGB 64GB (2 x 32GB) DDR4 3600 XMP disabled. GIGABYTE AORUS GeForce RTX 4090 24GB GDDR6X PCI Express 4.0, CORSAIR AX1600i power supply. Several SSDs are installed: a 1TB Samsung SSD 850 EVO, an 8TB Samsung 870QVO, and a 4TB Samsung 860 EVO. I also have Windows installed on a 1TB Samsung SSD, plus Steam and library files only on the 8TB drive. Other game launchers like Epic and Origin are available on the 8TB drive. I’m checking the PCIe slot for stability and potential crash causes this weekend. Thanks for all the advice. Also, I’ll be testing your suggestions over the weekend. At WhatIsThis? I’ll also examine the PCIE connector for any issues. Thanks all for your responses. By the way, I’ve added AMD Ryzen Master for temperature monitoring. Now I run three programs: Ryzen Master, Open Hardware Monitor, and iCue from Corsair. They’re on a secondary monitor. I was closely watching during gameplay when the crash occurred. Played for a few hours, and nothing happened. CPU temperatures stayed between 60°C and 68°C. Ryzen Master indicates a max temperature of 90°C, which seems to be the threshold for shutdown. I’m noting that when I first installed Ryzen Master, it reported normal operation and the system was only running for a short time.
About five minutes after my reply, my system crashed again while sitting on the desktop. Could a faulty external USB hub feeding power back into the motherboard be causing these issues? Think about other possibilities before trying the suggested fixes.
Disconnect any non-essential devices and check for crashes. If they persist, reattach them gradually until issues reappear.
ok i know its been a while but ill share an update. i had the crash happen while the USB hub was plugged in. When it crashed i unplugged the hub and plugged all the usb into the motherboard after about 4 hrs it crashed again. So i took the computer down off the wall and removed the video card and inspected the area around the PCIE connection point to look for cracks. i did not see any. I plugged everything back in and put the computer back up on the wall and plugged everything in including the USB hub. in my haste to plug everything in i did not plug in the DATA connection (usb) from my Corsair AX1600i power supply into the mother board. the computer this was saturday afternoon and my computer did not shut off until Tuesday evening when i went to bed. i have had absolutely no issues as of yet. one other thing to note here as well. i opened ryzen master to view more cpu temps to see if i had a temp sensor issue and was causing the crash perhaps and i changed to a profile by accident and im not sure which one but i have noticed that CPU temps are down about 5 -6 F including in games however some times the CPU does get upto 150 F (65.5C) but either way between the two i have not had a single issue since Saturday.