I am running an experiment in 4 different computers with identical builds.
The psychopy version that I am using is 1.80.
In all 4 computers I am running the exact same copy of an experiment I designed in the builder using v1.80. I have tested around 40 participants and I got 5 random crashes. The screen remained grey and when I brought the task manager up it was showing that psychopy was not responding. In the psychopy output I could see the message "avbin could not load" which does not make much sense as this happened during the experiment and not at the beginning, and only happened 5 times.
Anyone had a similar experience? Is it a version bug?
I am just curious why it happened only a few times and in different computers and not only in one.
Thank you,
Lazaros.
Related
Over the past couple months I have been experiencing BSOD's (some for other reasons but now it's just this one exe) and occasional black screen's.
I have gone through what I believe to be every driver and updated them, ran the windows memory diagnostics tool and the driver verifier and ran 2.5 passes of Memtest and had no issues with any of those, reset my computer to factory default (which is why I don't have the minidumps that I had before), and looked up everything I could trying to troubleshoot this issue. I'll take any good advice I can get from this point on and will answer any questions I can. Here are the mini dumps I have so far:
https://drive.google.com/drive/folders/1VqgX2KXoM32E6K0jAng-WoHZXDI8SOv1?usp=sharing
In the last week or two I have seen frequent disconnects while trying to run a lengthy training run. A month or two ago this seemed to be working pretty reliably. My code has definitely changed but those internal details seem unrelated to the operation of Colab.
(On the other hand, I did switch my local machine from an Intel MacBook Pro running Big Sur to an M1 (Apple Silicon) MacBook Pro running Monterey. I assume that does not matter to Colab running in the cloud, via a Chrome browser.)
I see two kinds of disconnects:
There are “faux disconnects” which seem like false positives from
the disconnect detector. These last less than a second, then the
computation continues apparently unscathed. A black notification
slides up from the lower left corner of then window, then slides
back. See a link to a video of this below.
Then there are “real disconnects.” I start a computation that I
expect to run for several hours. I see “faux disconnects” happen
frequently. But less than an hour into the computation, I find
the Colab window idle, no status information, and a Reconnect button
in the upper right corner.
Link to video. I started this session around 1:03 pm. This video was recorded at 1:35 pm. Normally the training session should have run for several hours. Instead it died at 1:52 pm (~50 minutes into the run). See some additional comments in an issue at GitHub.
Can anyone help me understand how to get past this? I am currently unable to make progress in my work because I cannot complete a training run before my Colab runtime decides to disconnect.
Edit:
FYI: since once a “real disconnect” happens it is too late to look at the (no longer connected) runtime's log, and since this seems to run for about an hour before disconnecting, I saved a log file when a run was about 10 minutes in.
Edit on August 1, 2022:
My real problem is the “real disconnect” on my real Colab notebook. But my notebook is overly complicated, so not a good test case. I tried to make a small test case, see Colab notebook: DisconnectTest.ipynb. It contains a generic NIST-based Keras/TensorFlow benchmark from the innertubes. I made a screen grab video of the first 2.5 minutes of a run. While this run completes OK — that is, there are no “real disconnects” — it had several “faux disconnects.” The first one is at 1:36. These seem fairly benign, but they do disrupt the Resources panel on the right. This makes it hard to know if the source of the “real disconnect” has anything to do with exhausting resources.
As I described in a parallel post on Colab's Issue #2965 on Github, this appears to be “some interaction between Colab and Chrome (and perhaps macOS Monterey (Version 12.5.1), and perhaps M1 Apple Silicon). Yet Colab seems to work fine on M1/Monterey/Safari.”
As described there, a trivial Colab example fails on Chrome browser but works fine on Safari.
I have recently started exploring game dev and wanted to do it using the Unreal Engine(4). However, the editor doesn't seem to be loading on my computer. I have displayed the UE4 window I keep having to look at upon launching the engine.
Could anyone please help me with this problem?
Thanks.
I'm no expert in Unreal Engine, and I don't know how long you've waited previously (do tell!), but UE4 is a massive, memory intensive engine that would struggle on any laptop (especially a Macbook). I personally use it on my laptop (an HP Pavillion) so it is possible, but there have been times when I am trying to open a project and I've had to wait for around 30 minutes for the percent to change (it was compiling shaders silently). Although, I've never seen it take too terribly long on startup (not opening a project). Try waiting for 30 minutes and see what happens (if you haven't already), otherwise I'm sure you know Unity is a lighter-weight option with comparable features.
I am having a problem on my Windows 8 64bit (legitimate) computer. I've got all the drivers for my motherboard, and in the last few weeks I have realised that smss.exe is using up to 40% (average of 30%) of my CPU. When it starts doing this, it can cause crazy lag in my games, even though I have a very high-spec PC.
The file is located in system32 and I've ran lots of AV scans (from Microsoft defender and MalwareBytes). In addition to this, I've also scanned for disk errors on all drives, and replaced the smss.exe from a working PC, but the problem still occurs.
A system restore is not an option here.
If there is no solution, is there any possible way to force the priority of the process to low so my games are playable please? At present, the process cannot be terminated, or edited at all - even the affinity.
Couldn't find the solution. After a lot of work, research, repairing Windows files I was lost. I even manually repaired a lot, but my Windows install was 2 years old. The only fix was to back it all up, reset the PC and run all the same programs again, 1 by 1, and no error has occurred. Odd.
Preface
My knowledge of WCF, and named pipes is less than zero. This is a question I am asking out of necessity, not desire. I'm trying to troubleshoot something.
Question
Is there any kind of tool, program, or place in Windows to see everything that is using WCF Named Pipes, and their origins, so that I can find out what is blocking my tool from working? More details below.
Problem
I use a programming plugin called JustCode from Telerik. It is not working for me on my new computer, so I have been struggling to find out why. I have been in contact with Telerik technical support and review of the log files suggests that the problem is that something on my computer is incorrectly using WCF Named Pipes.
Attempts to further diagnose this led to me completely wiping the computer clean (secure 0 overwrite of the entire hard drive) and reinstalling Windows (8.1 Professional x64) from scratch 30 times, installing nothing except the chipset INF driver, then Visual Studio 2013 Professional with Update 3, then JustCode - in that exact order. No Windows Updates, and no other drivers.
22 of 30 installs, JustCode did not work correctly. However 8 times it did work fine. These are extremely bizarre results and very confusing to me.
I have attempted this same test on 2 other machines, each with identical hardware except the motherboard and processor. My system uses a Haswell i7 (AsRock Z87 Extreme 9/ac motherboard), the other two machines used an IvyBridge i7 CPU and compatible motherboards (ASUS Maximus IV Extreme, Gigabyte GA-X79-UP4)
Here are my results;
AsRock
22 out of 30 failed
ASUS
16 out of 30 failed
GIGABYTE
3 out of 30 failed
I realize that correlation does not directly mean causation, but it is the only lead I have so far.
As a temporary fix, I can run Visual Studio as Administrator and the tool works. But I'd like to avoid having to do that every time for a number of various reasons.
So there it is; With so little installed, I have to conclude there is some native behavior on some piece of hardware that is doing this. Having 0 knowledge of WCF or 'named pipes', I need to try and find a way to look at them and see which part is doing it.