Infor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It
infor ln bshell process using 100% cpu
Also searched as
- bshell not responding infor ln
- infor ln session hangs bshell.exe
- baan bshell process stuck at 100 percent
- infor ln application server high cpu
Short answer
A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.
Applies to: Infor LN 10.x (10.5-10.7) on Windows and UNIX/Linux application servers; the bshell runtime is the same core component back to Baan IV and BaanERP
Diagnose and clear a hung bshell process
- 1On Windows, open Task Manager on the LN application/enterprise server and sort by CPU; on UNIX/Linux run top or ps -ef | grep bshell to find the offending process ID (PID).
- 2Match the PID to a user session in the Sessions Monitor (Tools > Session Management > Sessions) and confirm it has been Active far longer than that type of session normally runs.
- 3Check what the session was doing before the hang: a 4GL loop with no exit condition, a report scanning an unindexed table, or a wait on a database lock are the three most common causes.
- 4If the process is genuinely stuck, end the session from LN's own Sessions tool first, so shared memory and semaphores are cleaned up properly, rather than killing the OS process directly.
- 5If that does not clear it, kill the OS process (taskkill /PID on Windows, kill -9 on UNIX/Linux) and run any orphaned-resource cleanup your platform provides (ipcs/ipcrm on UNIX for leftover semaphores).
- 6Check the database for a blocking lock tied to the session (sp_who2 or sys.dm_exec_requests on SQL Server, v$lock on Oracle) and release it if the process is gone but the lock remains.
- 7Review the session's own trace or log output for the last statements executed, to identify the exact program or report that triggered the spin.
- 8If the same program repeatedly causes this, route it to development: it is almost always a missing index, a missing loop exit condition, or a DAL event calling itself indirectly.
What bshell actually is
bshell is the runtime engine that executes compiled Infor LN 4GL programs. Every LN session, whether opened from the Windows client, the web UI, or a batch job, runs inside its own bshell process on the application (enterprise) server. When a session looks frozen to the user, the underlying bshell process is almost always still alive and either spinning on CPU or waiting on a resource.
Because bshell processes are one per session, a single runaway session shows up as one process pinned near 100% CPU rather than the whole server slowing down evenly. That is the first useful signal: check per-process CPU, not overall server load, before assuming a system-wide problem.
The three real causes
Most bshell CPU spikes trace back to one of three things: a custom 4GL program stuck in a tight loop with no reliable exit condition, a report or query scanning a large table without a usable index, or a session waiting on a database row or table lock held by another process. Only the last one is not actually a CPU problem, it just looks like one because the client appears frozen.
Custom code is the most common offender in practice. A DAL trigger or table event that ends up calling itself indirectly, or a report loop that never advances its cursor, pins CPU at 100% indefinitely because LN does not impose a default execution time limit on 4GL code.
ps -ef | grep bshell
top -p <PID>
taskkill /PID <pid> /F (Windows)
kill -9 <pid> (UNIX/Linux)
Confirming it is a lock, not a loop
If the bshell process is using very little CPU but the user still cannot proceed, it is waiting, not looping. Query the database for blocking sessions and match the client connection back to the LN session through the Sessions Monitor or the connection's program name.
Clearing the block by committing or killing the blocking transaction resolves the symptom immediately, but always find out why that transaction was left open, a client that crashed without a commit or rollback, or a batch job that failed mid-transaction, so it does not recur.
Preventing repeat hangs
Index the tables used by custom reports and DAL queries, particularly ones filtered on non-key fields; an unindexed filter on a large transaction table is a very common trigger on sites where Baan IV or BaanERP data was migrated into LN without revisiting custom indexes.
Add explicit exit conditions and iteration limits to custom 4GL loops, and review any DAL event that could call the same table's events recursively. Move heavy batch reporting to job queue windows rather than interactive sessions where possible.
Common pitfalls
- !Killing the OS process without ending the LN session first, which can leave orphaned semaphores and shared memory that keep a license slot marked as in use.
- !Assuming every high-CPU bshell is a bug in custom code; an unindexed standard report against a very large table can do the same thing on data-heavy sites.
- !Not checking for a database lock before troubleshooting the process itself, which wastes time chasing a CPU problem that is really a blocking transaction.
- !Restarting the whole application server to clear one hung session, when ending the individual session or killing one process is usually enough.
- !Not correlating the OS process ID back to a specific user and program before killing it, which makes root cause analysis afterward much harder.
How an ERP-grounded AI assistant handles this
An AI assistant grounded in the LN environment (Netray's ERPray) can shortcut the diagnosis: pointed at the Sessions Monitor, the application server logs, and the database's active session list, it can correlate a high-CPU bshell process with the user, program and table involved in seconds, and note whether that program has hung before. It does not kill processes or end sessions itself, that stays a controlled admin action, but it removes the manual log-and-lock hunting that normally takes the first stretch of this kind of incident.
Frequently asked questions
Is bshell a virus or malware?
No. bshell (or bshell.exe on Windows) is the legitimate Infor LN 4GL runtime process. Antivirus tools sometimes flag it because it is unsigned or runs from a non-standard directory, but it is a core part of the LN application server and should not be removed.
How many bshell processes should be running?
Roughly one per active LN session, plus a smaller number for background job queue workers. If you see far more processes than logged-in users, check for orphaned sessions that failed to close properly and clean them up through the Sessions Monitor.
Can I set a CPU or time limit on bshell processes?
LN itself does not offer a built-in execution timeout for 4GL programs. Some sites use OS-level process limits (Windows Job Objects, UNIX ulimit or cgroups) as a safety net, but the better fix is correcting the underlying loop or missing index.
Why does this happen more often right after a data migration?
Newly migrated tables often lose custom indexes that existed in the legacy environment, or grow far larger than the test data used before go-live. Reports and DAL queries that were fine on a small dataset can scan millions of rows and pin CPU once real volumes are loaded.
Related
Infor LN Not Authorized to Run This Session: How to Fix It
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
Error fixInfor LN DAL Out of Sync After a Custom Field: Cause and Fix
Infor LN throws a DAL, or table, out of sync error, or simply drops a new custom field silently, when a table's dictionary definition is changed but the generated DAL and dependent forms are not regenerated afterward. Running the standard sequence, table compile, DAL generation, then session/form compile, in Tools > Development after every dictionary change resolves it. Skipping any one of the three steps is what causes the mismatch.
Error fixInfor LN Jobs Stuck in Active or Waiting: Fix the Job Daemon
Infor LN background jobs, reports, batch processes and print jobs, get stuck in Active or Waiting status when the job daemon on the enterprise server has stopped or lost its connection, or when a prior job crashed without releasing its status. Restart the job daemon and reset the stuck job's status through the Jobs session, and the queue resumes. A daemon that keeps stopping usually points to a memory, license or database connectivity problem on the server.
Error fixInfor LN Reports Stuck in the Print Queue: Device and Spooler Fix
Infor LN reports and forms stay queued and never reach the printer when the target device definition points to a printer that is offline, or the print listener on the print server has stopped. Check the device's status in Common > Printing > Devices, confirm the underlying OS printer is reachable, and restart the print listener if jobs remain queued after the printer itself is fixed. Most cases trace back to a genuinely offline printer, not an LN bug.
AdvancedHow to extend business logic in Infor LN with DAL2
DAL2 lets you add custom validation, defaulting and calculation logic to Infor LN Enterprise Edition tables by writing a Java business logic handler class and registering it against a table event, without editing the standard DAL. Because the logic sits in your own package rather than inside Infor's base code, it survives upgrades that would otherwise overwrite a direct DAL change.
AdvancedHow to create a custom session in Infor LN Studio
Infor LN Studio's session designer generates a new maintenance, overview or detail session from a table definition, then lets you arrange fields, attach DAL2 validation, and wire menu access, all inside a custom package so the session survives upgrades. Building on a custom table gives the lowest upgrade risk; extending a standard table needs more care and re-testing after every release.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
AI for ERPAI for Infor LN in Aerospace and Defense Manufacturing
AI grounded on Infor LN project, contract, and configuration management data for aerospace and defense manufacturers, with on-prem deployment for ITAR.
Stuck on Infor LN (Baan ERP)?
Talk to engineers who work inside Infor LN (Baan ERP) every week, and who build private AI that answers these questions from your own ERP data.