Category: KERN-EXEC

0

This panic is raised when the Kernel Executive 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).

1

This panic is raised as a result of trying to suspend a thread, set the priority of a thread or set the priority of a process. The panic occurs when:

• the process, which is the target of the set priority operation, is protected and is not the same as the process invoking the set priority operation

• the thread, which is the target of the suspend or set priority operation, is protected and is not the same as the thread invoking the suspend or set priority operation.

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 dreferencing NULL. Among other possible causes are: general protection faults, executing an invalid instruction, alignment checks, etc.

4

This panic is raised when the Kernel attempts to free a message, an RMessage, when that message is not in the accepted state. This panic is probably caused by a breakdown in client/server relations.

6

This panic is raised by the Kernel when the current thread attempts to read from a chunk using RChunk::Read() and the specified start position is one of:

• negative

• greater than or equal to the current number of bytes committed to the chunk. i.e. the value returned by the RChunk::Size().

7

This panic is raised by the Kernel when the current thread attempts to write to a chunk using RChunk::Write() and one of the following is true:

• the specified start position is negative

• the specified start position is greater than or equal to the current number of bytes committed to the chunk, i.e. the value returned by RChunk::Size()

• the specified start position plus the length of the descriptor passed to RChunk::Write() is greater than the current number of bytes committed to the chunk, i.e. the value returned by RChunk::Size().

9

This panic is raised by the Request() member function of the DLogicalChannel() Kernel object, which issues asynchronous requests to a device. The panic is caused when a request, as identified by the specified request number, has previously been made and this request is still outstanding.

10

This panic is raised by the Request() member function of the DLogicalChannel() Kernel object, which issues asynchronous requests to a device. The panic is caused when the specified request number is greater than or equal to the maximum number of requests supported per device driver (defined by the constant KMaxRequests in k32std.h). The panic also occurs if the request is invalid.

12

This panic is raised by Kern::EventCaptureHook() if an event capture hook has already been designated.

13

This panic is raised by Kern::EventReleaseHook() 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 user process to an illegal value, or to set the priority of a user thread 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.

17

The panic is raised when the Kernel tries to close a thread's heap and finds that the access count is negative. As the heap may be shared, the owning process is panicked.

18

This panic is raised by the Request() member function of the DLogicalChannel() Kernel object, which issues asynchronous requests to a device. The panic is caused when the current thread is different from the thread which created the channel.

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 RServer, 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 e32svr.h) is made while a previously made request is still outstanding.

21

This panic is raised when registering the screen-switch-on handler; the panic occurs when the handler is not the window server.

24

Introduced in 6.0: This panic is raised when the maximum length of the descriptor passed to RProcess::CommandLine() is smaller than tbe length of the command line data.