Kernel error when running a compute instance the second time - websocket

The compute instance works fine when I first create it. I get a "Kernel error" the second time I try to access a compute instance. The kernel drop down menu is unavailable and it says "No kernel connected". When I try to open terminal, I get the following message:
enter image description here
Appreciate the help
I tried restarting the kernel as the trouble shoot suggested

Related

Why can't code::block build file everytime every time after I restart my computer?

The code::block can't build file everytime after I restart my computer. It will show that there is error like this:
enter image description here
or "A debugging checking in this application has failed" like this and sometime it even can't allow me to open a new project:
enter image description here
But the strange thing is that when I first download the app and before I turn off the computer, it can build and run the same programe. This situation only appears when I turn off and turn on the computer again. However, when I reinstall the app, it can build and run the programe.
Can anyone please help me, I need the code::block tomorrow and it is impossible that every time after I turn off the computer I need to reinstall it.
I have tried to reinstall it, and open project in different way.

Debugging on an end-user PC?

A user that works in my company has an Error 13 Type mismatch in the moment that she wants to input some data in a grid.
The thing is that when she has that problem, my application only shows the error screen and nothing more (I mean it doesn't say where the error occurs).
I want to know if there is a way that I can "see" the problem in a debug application because I don't have the source code of my application in this computer and I don't know if the problem is because of a Windows configuration issue or why this error pops up provided that when she uses another terminal, different to the one that she normally uses, she can do her job without problems (they have the same settings in the two pcs).
I have the source code in my terminal but as say above, in my terminal the error doesn't pop up so I need to see it in her terminal.
How can I do this?

Breakpoint on entry point of PE is failed

I'm trying to get log of activity of my application with WinDbg. At the moment I'm on Win10 Pro x64. The entry point of my application is 0x10004D7EC. After start of WinDbg I press Ctrl+E to select my app. I input the next command
bp 10004D7EC
then hit F5 but WinDbg says that ERROR_PARTIAL_COPY has been occured (0x12B) so it seems that loading logexts is a bad idea because there is no garanty that information will be correct. So, how to fix this or maybe I do something wrong?
I believe that you're getting the error because you are putting your breakpoint on an invalid memory location. Check in the memory/disassembly window in windbg what is at this memory location - you'll probably find nothing there.
I guess that 10004D7EC is the address of your entry point on the disk - which might be different from the entry point address at runtime. You can search for the entry point with: x <your module name>!*<your entry point name>* (i.e. x myApp!*main*)

Getting NSContactsUsageDescription to work in 10.8.2

I have an app with a crash reporter that autofills in the user email address by getting it from ABAddressBook. I'm trying to get an informative message of intent in the dialog that 10.8 displays asking the user for permission. Following the advice at http://www.red-sweater.com/blog/2672/can-i-get-your-address , I've added the following to the app's Info.plist:
<key>NSContactsUsageDescription</key>
<string>blah blah blah</string>
Unfortunately, this is not working. The dialog still asks, but it does not display my description text. I've tried:
Putting this in the crash reporter framework's Info.plist instead of the app's.
Signing the app with my Developer ID cert.
But, alas, no luck. Anyone gotten this to work that can give me a tip as to what I'm doing wrong?
[UPDATE] I found the real reason why restarting helps. It kills the tccd process, which looks like the culprit in charge of displaying the message on that dialog.
So, just open Activity Monitor and kill the tccd process and your new message should just show up next time the dialog shows.
[Old Answer]
I was running into the same problem and wasn't really sure why (I was doing exactly what the documentation said to do). I finally got it working after:
Deleting the container my app was living in (~/Library/Containers/com.company-name.app-name)
Cleaning the build (In Xcode: Product -> Clean)
Restarting my machine (seems a little cargo-cultish, but I think this is what fixed the problem)
Building and running my app
The next time my app tried to access the Address Book API I was presented with the dialog that included my message.
I think Apple must be caching that message somewhere (either the message you want, or an empty string if you ran your code before you had a message to show), and the only way to clear it out is to restart. I tried the first 2 steps many times with no change in the message, even after I got the message working and then tried to change it.
Solution is to run this command in the Terminal:
tccutil reset AddressBook
Source: https://developer.apple.com/library/archive/qa/qa1906/_index.html

Can't open COM1 from application launched at startup

I'm using WinLIRC with IR receiver connected to serial port COM1 on Windows 7 x64. WinLIRC is added to Startup folder (Start->All applications->Startup) so it starts every time I log in. Very often (but not all the time) I see initialization error messages from WinLIRC, which continue for some time (couple of minutes) if I retry initialization, and after some retries it initializes correctly and works fine. If I remove it from Startup and start manually at any other moment it starts without errors.
I've downloaded WinLIRC sources and added MessageBox calls here and there so I can see what happens during initialization and found out that CreateFile call fails:
if((hPort=CreateFile(
settings.port,GENERIC_READ | GENERIC_WRITE,
0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0))==INVALID_HANDLE_VALUE)
{
char buffer[256];
sprintf_s(buffer, "CreateFile(%s) failed with %d", settings.port, GetLastError());
MessageBox(NULL, buffer, "debug", MB_OK);
hPort=NULL;
return false;
}
I see message box saying "CreateFile(COM1) failed with 5", and 5 is an error code for "Access denied" error according to this link.
So the question is why opening COM-port can fail with such error right after booting Windows and proceed normally few seconds or minutes later?
Update: the COM-port is the real one.
Update2: regarding the other application that opens serial port before WinLIRC. I did the following: I put Process Explorer to the Startup folder so it start on log in also, then rebooted. As soon as process explorer started I ran "Find Handle or Dll" dialog, put "Serial0" to the input and hit "Search". By that moment WinLIRC had already shown message box saying "CreateFile(COM1) failed with 5". Then I waited till the process explorer search ends, seen that it found nothing, then tried to reinitialize WinLIRC and it failed again. So I suggest that it is not the case of serial port being opened by other application. If anyone can suggest a better way to check it, I'll happily recheck.
When I search for "Serial0" in process explorer while WinLIRC is running it finds the winlirc.exe process, so it looks like it is correct term to search.
Update3: regarding the serial mouse driver. It is not listed in device manager, so I wasn't able to disable it there, however I have found this instructions on how to disable sermouse service and it didn't help.
Update4: one more thing I forgot to mention. It happens only if I log in soon after booting PC. If I leave windows on log in screen for several minutes and log in later, then WinLIRC initializes without any problems always.
Update5: Unfortunately, I don't have access to the computer that had this problem reproducing, so I can't experiment anymore.
It takes time to initialize the port.
Your application will run absolutely fine on windows XP.
Windows7's serial ports are virtual.
You can run a small code and check it out
using System.IO.Ports;
private void Form1_Load(object sender, EventArgs e)
{
string[] ports = System.IO.Ports.SerialPort.GetPortNames();
comboBox1.Items.Add("None");
foreach (string port in ports)
comboBox1.Items.Add(port);
comboBox1.SelectedIndex = 0;
}
This will return you the list of serial port. Check the status of it and display it on message box.
Make this code and run at startup. You'll get the root cause.
Here some links one has to visit before plunging into the magic world of serial programming in Windows :)
A detailed explanation of serial programming in Windows:
http://www.codeguru.com/cpp/i-n/network/serialcommunications/article.php/c5425/Serial-Communication-in-Windows.htm
a little bit outdated (the site states 1999-2003 so yes, it's outdated) but absolutely useful:
http://www.flounder.com/serial.htm

Resources