Currently i'm developing a Cocos2d application for Mac OS X using xCode 4.2.1.So my problem is,sometimes while running the program the system get's stuck and show me a message like this- You need to restart your computer.Hold down the power button until it turns off.Then press the power button again. After receiving this message i can't proceed further without restarting the computer. What might be the problem behind this issue. Can anyone help me out.
What You get is called a kernel panic.
Resolution
Restart your Mac with a Safe Boot and see if the kernel panic happens
again
In most cases, kernel panics are not caused by an issue with your Mac.
They are most likely caused by an issue external to your Mac. If the
kernel panic doesn't happen again within a few weeks, you don't need
to troubleshoot further.
Depending on the model of Mac you have, restart one of these ways:
• Press and hold the Power button for several seconds to turn off your Mac. Then, press the Power button to startup your Mac.
• If you have a Restart button, press it.
As soon as your Mac starts up, hold down the Shift key to start up with a Safe Boot into Safe Mode. Note: If you are using a third-party
external keyboard and cannot start with a Safe Boot, try using an
Apple keyboard instead.
If your Mac has a kernel panic starting up, or while in Safe Mode, jump to the "Troubleshooting a recurring kernel panic" section of this
article.
If your Mac starts up without a kernel panic after a Safe Boot, restart your Mac by choosing Apple Menu > Restart…, then let it start
up normally. Run Software Update and install all available updates
until Software Update reports "Your software is up to date". Mac OS X
updates improve the tolerance for external issues such as malformed
network packets. For most kernel panics, this is all you have to do.
Note: It is possible, although very unlikely, that something on your network is sending your Mac malformed network packets which could cause recurring kernel panics. If the hardware and software on your Mac checks out as OK, check the devices on your network. Make sure your router's firmware is up-to-date, and that the router is not malfunctioning. Refer to your router's manufacturer for service and support.
And You also can try to find the problem in kernel.log. Go to the console app in the utilities folder and then type this:
tail -f /var/log/kernel.log
It will print kernel.log file to Your console.
More information:
Kernel Logs from the Command Line in Mac OS X.
How to log a kernel panic.
Kernel Panic.
Related
We have an old legacy application that uses Mac address for validating a license.
Sometimes this license trips up when attempting to start the app without a network cable connected.
Is it possible with a registry tweak to change (or some other way) the order of what windows reports is the first Mac address? Ie. The order of what windows prints when you run the getmac command from a console window.
If its tripping up when there is no cable plugged in, maybe installing the MS loopback adapter is an option and get your legacy program to look at this mac id, as this should be on and working all the time.
https://support.microsoft.com/en-us/help/2777200/installing-the-microsoft-loopback-adapter-in-windows-8-and-windows-ser
run C:\Windows\System32\hdwwiz.exe, and step through the wizard.
I'm running macOS Sierra, but same experienced on High Sierra.
When I open the Simulator in Xcode 9.1, it doesn't load anything (sometimes a red screen), however crashes the whole system. I can move the mouse, but everything is unclickable.
Really rarely it receives clicks and I can open the Activity Monitor to shut it down. Restart doesn't help, because Simulator is reopened then, and crashes the whole system again.
Is there anyone out there experiencing the same issue? Any solutions, suggestions?
Could this relate to the fact that I have a Hackintosh?
We can't provide support for pirate copies of macOS running on non-Apple hardware. I would encourage you to purchase authorized Apple hardware which comes with a legal copy of macOS.
Red is the canary texture indicating the GPU didn't write anything to the surface. It is probably a rendering failure due to graphics driver bugs. You can check the logs in cases where it doesn't fully restart and you may find GPU restarts are taking place. If the GPU restart fails then the system will panic and reboot.
Edit: As I previously indicated, you're running untested hardware on a hacked copy of macOS using unknown drivers. If you're using built-in drivers it may be a mis-match between the hardware they expect and the GPU you have. If you're using vendor-provided drivers it may be a simple bug. And when running any non-standard kernels or kernel extensions there could be a vast array of possible causes (bad kernel extension corrupting some data structure, etc)
I got a completely new PICkit 3, MPLAB X on a MacBook Pro and the PIC16F1827. I set up a new project with the xc8 compiler and, to my knowledge set up everything correctly. Then I connected my PICkit and thought that it would start downloading and flashing a new firmware.
Instead it just flashed the STATUS LED red and nothing happened. I have power on the PICkit and the connection is active.
This is what I get, when trying to start a debugging session:
I tried reinstalling MPLAB X and to switch the USB Cable, in case it was faulty. Any suggestions?
The fault was actually Apples System Integrity Protection, which prevented the installer from changing vital permissions of one installation folder. By now this has probably already been resolved in the new versions.
But in case anyone still needs it:
Reboot your mac into recovery mode.
Open the terminal.
Type csrutil disable #this disables the SIP on your machine
Reboot and install MPLAB X
Reboot into recovery again and reenable SIP (with csrutil enable)
Usually, when a tool is detected, the serial number appears below its name. I believe your PICkit3 is not being detected. Do you have it connected directly to the USB port on you computer? Sometimes they don't get recognized when connecting through USB hubs.
I am new to windows driver development, so please bear with me if my question is being too stupid. Well, I am not sure why, as MSDN suggested and also the way I perceived, the host computer, e.g developing the driver, and the target computer, e.g debugging the driver, need to be two separate ones. why such separation? I did try to merge those two by deploying and debugging a driver on the host computer, in which I am developing a driver, and it seemed work with no objection from windows. Thanks.
PS. Source like this http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx got me think so.
Practically, when you are developing and testing a driver, in many situation you will get system crash (BSOD) and your system may not be bootable. In such situations your development + debugger environment is also gone/in-accessible.
Two separate machines are required for kernel debugging. You cannot debug self by obvious reasons (a debugger and a debuggee are in the same kernel and a deadlock appears). Of course, the target machine can be a virtual one.
When we develop a driver and test it the system will crash and a blue screen (called BSOD - blue screen of death)will show up. This is not the case like developing a User mode application and it crashed due to a memory error. Your driver will be running as a kernel mode application , If it crashes due to any illegal memory operation then the whole system is gone. It is not a simple issue to resolve , You need to log into safe mode and remove the driver from your system to recover it.
Due to this it is preferred to use a target machine mostly a VM on which the driver is installed and a host machine there we will be using a debugger to debug the driver.
I'm developing a KEXT on mac using Xcode, After every compile I'm changing permissions through terminal and load the KEXT, then reading results from console app. Some of the mistakes in development giving system a kernel panic and I have to restart my mac, this is so annoying. I was wondering if there is a better way to develop and debug a KEXT?
This is too big a topic for an answer, but it is at least well documented, look at these documents from Apple:
When Things Go Wrong: Debugging the Kernel
Debugging a Kernel Extension with GDB
Technical Note TN2063: Understanding and Debugging Kernel Panics
Also note that you can get the output from kprintf() logging calls via Firewire (using the fwkpfv command-line utility on the other Mac) or Serial Port (mainly useful for testing in VMs, as modern Macs don't have serial ports). kprintf is synchronous, so unlike the kernel.log you will see the debug output even if it occurs immediately before a crash.