Maybe not the appropriate place to ask but I keep getting BSOD’s when launching Jupyter Notebook via Anaconda Navigator. This is part of the Moving off-platform module within the Data Science Career Path.
I am running on a fairly beefy desktop PC – 9900K 2080 ti 32 GB RAM-- GPU/CPU are OC’d but didn’t think that would be applicable here. Anybody have ideas how to troubleshoot?
Hmm no, that seems like a unique situation. I think it would be worth trying to debug in the shell instead of the navigator though as the console output is useful. You could try digging a little deeper yourself e.g try just running up the server without opening the browser- jupyter notebook --no-browser (can you still open the server page, what about simple text documents instead of notebooks?). If that breaks then do other similar conda tools like ipython fail? If you can narrow down the cause of the issue the next steps would be easier.
If you can’t hunt in down yourself then you’d want to hit the conda FAQs and web search for similar issues. Good luck 
.
If the problem is severe enough that Windows is falling over completely and you’re getting the smiley face of doom, then it’s not necessarily something with Jupyter/conda… BSoD’s pretty much always come from something at the system level, like driver or hardware faults for example.
The error code at the bottom of the screen would be the best place to start trying to figure out the issue. This might not be displayed for very long, especially so if you have a high-spec machine as Windows will be able to dump the kernel and reboot much faster. If you want to disable the automatic restart on system failure so you can actually see the error, you can do that from the Advanced System Settings, under “Startup and Recovery”.
Obvious warning: You make adjustments to your system at your own risk. (There’s some presumption that you’re comfortable doing so to some extent though, since you’re overclocking your hardware.)
You might also be able to glean some information as to what is happening from the Event Viewer.
If you’re technically inclined…
Windows ought to dump at least some of the system state to disk when you encounter a bugcheck, usually the default is to dump to %systemroot%\MEMORY.DMP. If that file is there and the timestamp correlates with your BSoD, if you’re inclined to do so you can use the Debugging Tools for Windows (WinDbg) to parse the dumped data and analyse what caused the error.
Simply pointing WinDbg at the dump ought to result in some output like the following, which would show the error code and faulting component:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck EF, {ffffa586380c1580, 0, 0, 0}
Probably caused by : ntdll.dll ( ntdll!RtlpHpFreeWithExceptionProtection$filt$0+44 )
Followup: MachineOwner
---------
From which, the suggestion is that the fault was in ntdll.dll and the error (EF) was CRITICAL_PROCESS_DIED. You’ll have a different error, probably, but this information ought to be sufficient to point you to the root cause of your problem.
The debugging tools are part of the Windows 10 SDK, if you want them.