Category: KERN-EXEC

These panics represent program errors which are detected by the Kernel Executive. Typically, they are caused by passing bad or contradictory parameters to functions. Threads which cause exceptions also raise a KERN-EXEC panic.

The thread causing the panic is terminated.

`0`	This panic is raised when the Kernel cannot find an object in the object index for the current process or current thread using the specified object index number (the raw handle number). The most common reason for this is trying to use a kernel-side resource without first having successfully created it or successfully opened it. Typically, such resources are created or opened through user side handles, which are instances of classes derived from `RHandleBase`, for example, `RLibrary`, `RThread`, `RProcess`, `RSemaphore`. (Note that this list is not exhaustive). For example, a call to `RLibrary::Lookup()` panics with KERN-EXEC 0 if not preceded by a successful call to `RLibrary::Load()`.
`1`	This is a general panic raised as a result of trying an unauthorized activity such as trying to suspend a thread, to set the priority of a thread or to set the priority of a process, when not authorized to do so.
`2`	This panic is raised by the kernel when opening a kernel side object, a DObject type, and the full name is invalid. The full name is deemed to be invalid if it contains a character that is not one of the printable characters lying between 0x20 and 0x7e inclusive, or it contains an asterisk or a question mark. See also Kern::ValidateFullName().
`3`	This panic is raised when an unhandled exception occurs. Exceptions have many causes, but the most common are access violations caused, for example, by dereferencing NULL. Among other possible causes are: general protection faults, executing an invalid instruction, alignment checks, etc.
`4`	This panic is not used.
`5`	This panic is not used.
`6`	This panic is raised by the kernel when a handle to a code segment is invalid.
`7`	This panic is not used.
`8`	This panic is not used.
`9`	This is a general type of panic that is usually raised by a device driver when dealing with an asynchronous request, and it finds that an asynchronous request is already outstanding. For an example of the context in which this is raised, see `...\cedar\e32test\examples\driver1\driver1_ldd.cpp`. This panic is also raised when trying to subscribe to a property through a call to `RProperty::Subscribe()` and there is already an outstanding subscription on this property handle.
`10`	This panic is raised by DLogicalChannel::Request() when the request number passed to the function is smaller than the permitted minimum. See also DLogicalChannel::EMinRequestId().
`11`	This panic is raised when creating a logical channel, and the unit number is outside the permitted range: If unit numbers are not permitted, the unit number value must be KNullUnit. If unit numbers are permitted, the unit number value must be less than KMaxUnits. A logical channel is created as a result of a call to `RBusLogicalChannel::DoCreate()`.
`12`	This panic is raised by the kernel if an event capture hook has already been designated.
`13`	This panic is raised by the kernel if the current thread is not the designated event capture hook.
`14`	This panic is raised when an attempt is made to set the priority of a thread or process to an illegal value. The permitted priority values for a user process are a subset of the values defined by the TProcessPriority enum. The permitted values are: `EPriorityLow` `EPriorityBackground` `EPriorityForeground` `EPriorityHigh` The permitted priority values for a user thread are a subset of the values defined by the TThreadPriority enum. The permitted values are: `EPriorityMuchLess` `EPriorityLess` `EPriorityNormal` `EPriorityMore` `EPriorityMuchMore` `EPriorityRealTime` `EPriorityAbsoluteVeryLow` `EPriorityAbsoluteLow` `EPriorityAbsoluteBackground` `EPriorityAbsoluteForeground` `EPriorityAbsoluteHigh`
`15`	This panic is raised when a timer event is requested from an asynchronous timer service, an `RTimer`, and a timer event is already outstanding. It is caused by calling either the `At()` , `After()` or `Lock()` member functions after a previous call to any of these functions, but before the timer event requested by those functions has completed.
`16`	This panic is not used.
`17`	The panic is raised if kernel heap checking has failed.
`18`	This panic is not used.
`19`	This panic is raised by the Kernel when a server program makes a request to receive a message, i.e. when it calls the `Receive()` member function of `RServer2`, the handle to the Kernel side server object. The panic occurs when a receive message request has previously been made and is still outstanding.
`20`	This panic is raised by the Kernel when a request for an event, as originated by a call to UserSvr::RequestEvent(), defined in the `e32svr.h` file, is made while a previously made request is still outstanding.
`21`	This panic is not used.
`22`	This panic is not used.
`23`	This panic is raised in a call to `RSessionBase::ShareAuto()` or `RSessionBase::ShareProtected()`, when attempting to create a session with a server that can be shared, and the server does not allow or support shared sessions.
`24`	This panic is raised when writing global DLL data, and the length of data to be written is greater than the space available.
`25`	This panic is raised when searching for objects, using the internal function `TFindHandleBase::NextObject()`, and an invalid type of object is specified; i.e. it is not a thread, process, chunk, mutex etc. etc.
`26`	This panic is raised by kernel side code that implements heap debugging behavior, when a specific debug request is not recognized.
`27`	This panic is raised when an executive call is made with an invalid call number.
`28`	This panic is not used.
`29`	This panic is not used.
`30`	This panic is raised when an attempt is being made to send a synchronous message to a server more than once, using the current thread's dedicated synchronous message.
`31`	This panic is not used.
`32`	This panic is called by DProcess::Resume() when trying to resume a process that is still being loaded.
`33`	This panic is raised in a call to Kern::KUDesInfo(), Kern::KUDesPut(), when an invalid descriptor is passed.
`34`	This panic is raised in a call to Kern::KUDesSetLength() and Kern::KUDesPut() when the descriptor passed to it is not a modifiable type; i.e. is derived from TDesC but not derived from TDes.
`35`	This panic is raised in a call to Kern::KUDesSetLength() & Kern::KUDesPut() when the length of the source descriptor is longer than the maximum length of the target descriptor.
`36`	This panic is raised by the kernel side code that implements the setting of the currency symbol when the length of the currency symbol is greater than KMaxCurrencySymbol.
`37`	This panic is raised by kernel code when it tries to acquire the process DLL lock just before a load, and the wait DLL lock is invalid.
`38`	This panic is raised by internal kernel code when an illegal attempt is made to attach to a library.
`39`	This panic is raised when extracting a list of DLL entry points, and the number exceeds the maximum permitted.
`40`	This panic is raised by internal kernel code when an illegal attempt is made to detach a library.
`41`	This panic is raised by internal kernel code when an illegal attempt is made to attach to a library.
`42`	This panic is raised by internal kernel code when an illegal attempt is made to detach a library.
`43`	This panic is raised by kernel code when it tries to release the process DLL lock when a load fails, and the release DLL lock is invalid.
`44`	This panic is raised when a bad message handle is passed to the kernel. This usually occurs when using functions called on the `RMessagePtr2` or `RMessage2` classes after the message has been completed; or when the `iHandle` data member of the base class `RHandleBase` has become corrupt.
`45`	This panic is not used.
`46`	This panic can be raised as a result of a call to one of a large number of functions. In general, the panic indicates an attempt to perform an operation on a thread or process by code running in another process - violating the security principle of process isolation. There are exceptions to this general rule, for example, where the panic is raised because the calling process has insufficient capability. The precise reason is stated with the function(s). The panic is raised on a call to the following function if the process owning the thread performing the call is not the creator of the target process or, if a handle is specified, the handle is not local. `RProcess::SetParameter()` The panic is raised on a call to the following functions if the process owning the thread performing the call is not the same as the target process. `RProcess::Kill()` `RProcess::Terminate()` `RProcess::Panic()` `RProcess::SetJustInTime()` `RProcess::Resume()` `RThread::Kill()` `RThread::Terminate()` `RThread::Panic()` `RThread::Suspend()` `RThread::Resume()` `RThread::SetPriority()` `RThread::RequestComplete()` `RThread::RequestSignal()` NOTE: the creator of a new process can kill or panic the new process, change the new process priority and set the new process startup parameters until the process is resumed (which the creator can also do). After the new process has been resumed, then it becomes totally independent of its creator, and any attempt to panic it, kill it etc will raise the KERN-EXEC 46 panic. The panic is raised on call to the following functions if the calling process does not have the PowerMgmt capability (TCapability::ECapabilityPowerMgmt()): Power::PowerDown() Power::EnableWakeupEvents() Power::DisableWakeupEvents() Power::RequestWakeupEventNotification() Power::CancelWakeupEventNotification() The panic is raised on call to the following functions if the calling process does not have the WriteDeviceData capability (TCapability::ECapabilityWriteDeviceData()): `User::SetMachineConfiguration()` `User::SetHomeTime()` `User::SetUTCTime()` `User::SetUTCOffset()` `User::SetUTCTimeAndOffset()` The panic is raised on call to the following function if the calling process does not have the ReadDeviceData capability (TCapability::ECapabilityReadDeviceData()): `User::MachineConfiguration()`
`47`	This panic is raised when the user issues a request to be notified of messages or the availability of space, when a request has already been issued and is still outstanding. See `RMsgQueue`, asynchronous message queues.
`48`	This panic is raised when creating a message queue, and the size of the template parameter is invalid. See `RMsgQueue`, asynchronous message queues.
`49`	This panic is raised when creating a message queue, and the specified number of slots is not positive. See `RMsgQueue`, asynchronous message queues.
`50`	This panic is raised if an attempt is made to cancel an outstanding request to be notified of messages or the availability of space, and the cancel is being made by a thread in a different process to the one from which the request was originally made. See `RMsgQueue`, asynchronous message queues.
`51`	This panic is raised by `RProcess::Setparameter()` if a slot value is invalid.
`52`	This panic is raised by `RProcess::Setparameter()` if a slot is in use.
`53`	This panic is raised by `RProcess::Setparameter()` if the length of the data passed is negative.
`54`	This panic is raised by `RCondVar::Wait()` when the current thread does not hold the specified mutex.
`55`	This panic is raised when a call is made to `RThread::GetDesMaxLength()`, which is now obsolete.
`56`	This panic is raised on a process which has not yet been resumed, and whose creator has died.
`57`	This panic is raised when a session receives a message to connect to a server when the session is already connected to that server.
`58`	This panic is raised during an attempt to connect to a server. As part of this process, a pointer to an instance of the `CSession2` derived class is saved in the instance of the `CServer2` derived class. The panic is caused when the pointer to the session object is NULL.
`59`	This panic is raised during an attempt to connect to a server. As part of this process, a pointer to an instance of the `CSession2` derived class is saved in the instance of the `CServer2` derived class. This panic is caused when a pointer to the session has previously been set.
`60`	This panic is raised during an attempt to connect to a server. As part of this process, a pointer to an instance of the `CSession2` derived class is saved in the instance of the `CServer2` derived class. This panic is caused when a pointer to a session is being set, and the message is not the connect message.
`61`	This panic is caused when a real-time thread attempts to execute a non-realtime function.
62	This panic is raised by Kern::SetThreadRealtimeState when the state argument is invalid.
63	A bad descriptor was passed to a server over IPC, causing an exception when the kernel tried to update its length field.
64	An invalid notification type was passed to a shared buffers exec call handler.
65	An invalid parameter was passed to a shared buffers exec call handler.
66	An entropy estimate passed to an entropy buffer was outside the allowed range.