Troubleshooting “A Previous Instance of Genius Is Still Running” in SAG Infotech Genius

Overview

When launching SAG Infotech Genius on a Windows Remote Desktop (RDP) server, the application may display the following message:

A PREVIOUS INSTANCE OF GENIUS IS STILL RUNNING

After displaying this message, the application may close without opening its main interface. This article explains how to investigate this issue on a shared Windows server, check running processes and user sessions, review relevant application errors, and understand why restarting Windows may resolve the problem.

Environment and Problem Description

The issue discussed in this case occurred in the following environment:

• Application: SAG Infotech Genius
• Executable: D:\SAG Infotech\genius\Genius.exe
• Operating environment: Windows server accessed through Remote Desktop
• Affected user: WINVDI\administrator
• Affected user profile: C:\Users\Administrator

The problem was user-specific: Genius worked for other users on the same server, but the affected user could not open it. This difference was important because it suggested that the issue might be associated with the affected user's session or application state rather than a complete failure of the Genius installation. However, this observation alone could not establish the exact cause.

Step 1: Confirm the Error and Its Behaviour

First, launch Genius normally and note the exact error message. In this case, clicking OK closed the error screen, but Genius did not open. An error indicating that another instance is running does not, by itself, prove that a visible or active Genius window exists. The application might be detecting a process, an internal state, or another condition that prevents startup. The precise mechanism depends on how the application is designed. Do not assume that the message means a particular lock file or registry entry is responsible.

Step 2: Check Whether Genius.exe Is Running

Open PowerShell and run:

Get-CimInstance Win32_Process -Filter "Name='Genius.exe'" |
    Select-Object ProcessId, SessionId, ExecutablePath, CommandLine |
    Format-List

This command displays available information about running processes named Genius.exe, including their process IDs, session IDs, executable paths, and command lines. Pay attention to the following fields:

• ProcessId: Identifies a running process.
• SessionId: Identifies the Windows session in which the process is running.
• ExecutablePath: Helps confirm which copy of Genius is running.

A process with the same name may belong to another user. On a shared RDP server, it is essential to distinguish the affected user's process from processes belonging to other users. If the command returns no process, that does not automatically identify the cause of the error. The application may have exited before the check was performed, or the problem may involve another aspect of its startup logic.

Step 3: Identify the Owner of Each Genius Process

To associate a process with its Windows account, run:

Get-CimInstance Win32_Process -Filter "Name='Genius.exe'" |
    ForEach-Object {
        $process = $_
        $owner = Invoke-CimMethod -InputObject $process -MethodName GetOwner

        [PSCustomObject]@{
            ProcessId      = $process.ProcessId
            SessionId      = $process.SessionId
            User           = if ($owner.ReturnValue -eq 0) {
                                 "$($owner.Domain)\$($owner.User)"
                             } else {
                                 "Owner unavailable"
                             }
            ExecutablePath = $process.ExecutablePath
        }
    } |
    Format-Table -AutoSize

This helps establish whether a process belongs to the affected user or to another person using the server. During this investigation, Genius processes were observed in other sessions, including processes belonging to:

• WINVDI\mukul.bansal
• WINVDI\bison

These processes were not automatically treated as the cause of the affected user's problem. Important: Never terminate every process named Genius.exe on a multi-user server simply because one user cannot open the application. Doing so could interrupt other users' work.

Step 4: Observe the Process During Application Startup

A process may appear briefly and then exit. To observe what happens when Genius starts, use the following PowerShell commands:

$start = Get-Date

Start-Process -FilePath "D:\SAG Infotech\genius\Genius.exe"

Start-Sleep -Seconds 5

Get-CimInstance Win32_Process -Filter "Name='Genius.exe'" |
    Select-Object ProcessId, SessionId, ExecutablePath, CommandLine |
    Format-List

This test starts Genius, waits five seconds, and checks whether a process with that name is still running. Interpret the result carefully:

• If a process is present, investigate its session, owner, executable path, and behaviour.
• If no process is present, the application may have exited before the check.
• If the process appears and then disappears, further investigation may be required to determine why it terminates.

In this case, a launch test briefly showed a Genius process with a window title of Genius. The process was no longer present during a later check. This observation demonstrated that process state could change during troubleshooting. It did not establish why the application displayed the previous-instance message.

Step 5: Check the Affected User's Application Settings

If Genius works for other users, comparing the affected user's configuration with a working user's configuration may help identify a difference. The following PowerShell commands read two registry locations associated with the affected profile:

Get-ItemProperty -Path "HKCU:\Software\SAGInfo\Genius" `
    -ErrorAction SilentlyContinue

Get-ItemProperty -Path "HKCU:\Software\VB and VBA Program Settings\Genius\Settings" `
    -ErrorAction SilentlyContinue

The investigation found these values in the affected user's profile:

• ThinClient=0 under HKCU:\Software\SAGInfo\Genius
• DispCh=2.26.9 under HKCU:\Software\VB and VBA Program Settings\Genius\Settings

A working profile contained DispCh=2.26.9.1. This was a configuration difference, but no evidence established that it caused the startup error. The values should not be changed merely because they differ. Before making any registry changes, confirm the purpose of the setting with the software vendor, back up the relevant key, and ensure that the proposed change is appropriate for the installed application version.

Step 6: Check Application Files and Permissions

Application startup can be affected by file access, permissions, configuration files, or other dependencies. The investigation included checks of the Genius application folder and the affected user's profile. A search in the top-level application folder for filenames containing terms such as lock, mutex, instance, running, pid, and genius.lck did not identify matching files. No obvious application configuration or lock files were found in the profile locations that were examined. The application folder was writable, and the permissions examined appeared broadly adequate. These findings did not rule out every possible file-access, configuration, or application-state problem. A file search cannot establish that an internal lock does not exist, because the application might use a differently named file, a registry value, an operating-system object, or another mechanism. Avoid deleting unknown files, changing shared application permissions, or modifying the application installation without supporting evidence.

Step 7: Review Windows Event Viewer for Application Errors

Windows Event Viewer can provide additional evidence when an application fails to start or crashes. To check application errors:

1. Press Win + R.
2. Type eventvwr.msc and press Enter.
3. Expand Windows Logs.
4. Select Application.
5. Look for errors recorded around the time Genius failed to open.
6. Review the event's general details and, when available, its technical information.

In the investigated environment, historical .NET Runtime Event ID 1026 entries were found for Genius.exe. The recorded exception code was c0000005, with an address of 660CCB97 and no useful stack trace in the information examined. An exception code of 0xC0000005 is associated with an access violation. It indicates an attempt to access memory in a way that is not permitted. It does not, on its own, identify the underlying defect. The recorded events dated from earlier months. They were not sufficient to prove that the same issue caused the current previous-instance error. For useful correlation, prioritise events recorded at the exact time of the failed launch. Record the timestamp, application name, event source, event ID, exception code, and any available faulting-module details.

Step 8: Use Process Monitor if the Cause Remains Unclear

If the error continues, Microsoft Sysinternals Process Monitor can help capture the activity that occurs while Genius starts. Process Monitor can record operations involving files, the registry, processes, and threads. This may help identify relevant failures or unexpected application behaviour. A practical approach is:

1. Download Process Monitor from the official Microsoft Sysinternals website.
2. Run it with the required administrative permissions.
3. Configure filters to focus on Genius.exe.
4. Start capturing events immediately before launching Genius.
5. Reproduce the error.
6. Stop capturing and review the events around the failure.

Look for relevant access-denied results, missing-file attempts, unexpected process termination, or other errors. Do not interpret every failed operation as a fault: applications can make normal exploratory requests that return unsuccessful results. If necessary, preserve the capture for review by the software vendor or an experienced Windows administrator.

Step 9: Restart Windows — The Solution That Worked

In some cases, restarting the Windows system resolved the problem. After the restart, the issue that prevented Genius from opening was resolved. This was the confirmed practical outcome of the troubleshooting process. A restart can clear transient operating-system and application state by terminating running processes and starting a fresh Windows session. Depending on the underlying condition, it may also resolve a problem involving a process that did not exit cleanly or another temporary resource state. However, the successful restart does not prove which internal condition caused the error. The investigation did not establish a specific stale lock, registry value, or application defect as the root cause.

How to restart a Windows server safely

On a shared Remote Desktop server, a restart affects more than one user. Before proceeding:

1. Confirm that a restart is authorised.
2. Notify all affected users and the responsible administrator.
3. Ask users to save their work and close applications.
4. Choose an appropriate maintenance window.
5. Restart Windows using the organisation's approved procedure.
6. After the system returns, sign in and test Genius using the affected account.
7. Confirm that other required applications and services are working normally.

If the system is a production server, coordinate the restart with the system owner. Do not restart a shared server unexpectedly simply to troubleshoot one user's application.

Recommended Troubleshooting Order

For a similar incident, follow this sequence:

1. Record the exact error message and affected user.
2. Confirm whether other users can open Genius.
3. Check running Genius.exe processes and identify their session IDs and owners.
4. Observe the process during a controlled startup attempt.
5. Compare relevant user settings without making unverified changes.
6. Check application-folder access and permissions.
7. Review Event Viewer for errors matching the failure time.
8. Use Process Monitor if further evidence is needed.
9. If appropriate and authorised, schedule a Windows restart.
10. Verify the result and document any remaining symptoms.

If the problem returns after a restart, collect fresh logs and timestamps before making further changes. Repeated recurrence may justify escalation to SAG Infotech support.

Actions to Avoid

During troubleshooting on a shared Windows server, avoid the following:

• Do not kill every Genius.exe process. Other users may have active work in the application.
• Do not delete suspected lock files without evidence. Their purpose and ownership may be unknown.
• Do not change registry values based only on differences between users. A difference is not proof of a fault.
• Do not delete historical crash dumps simply to clear the error. They may be useful diagnostic evidence.
• Do not reinstall or replace shared application files prematurely. First establish whether the problem is limited to a particular user, session, or application installation.
• Do not restart a production server without coordination. A system restart can disconnect every active RDP user.

Frequently Asked Questions (FAQs)

1. What does “A Previous Instance of Genius Is Still Running” mean?

It means Genius has detected a condition that prevents it from starting because it believes another instance or an associated application state may already exist. The message alone does not prove that a visible Genius window or a currently running process exists.

2. Why does Genius work for other users but not one RDP user?

A user-specific failure can involve that user's Windows session, application settings, profile state, or other per-user conditions. These are possible investigation areas, not a diagnosis. Compare the affected and working environments carefully before changing anything.

3. Should I terminate Genius.exe from Task Manager?

Only terminate a process after identifying its owner and confirming that it is safe to close. On a multi-user server, ending another user's Genius process may interrupt their work. If the process belongs to the affected user, coordinate closure before terminating it.

4. Why did restarting Windows solve the problem?

A restart clears transient process and operating-system state and starts a fresh system session. In this case, the restart resolved the immediate issue, but the exact underlying cause was not established.

5. Does Event ID 1026 with exception code 0xC0000005 prove the cause?

No. The exception code indicates an access violation, but historical entries do not prove that the same failure caused the current startup message. Correlate event timestamps with the actual failed launch and gather additional evidence if the problem recurs.

6. Should I change the Genius registry settings?

Not without evidence that a specific setting is incorrect and reliable guidance on the intended value. A difference between working and affected profiles is a clue for investigation, not proof of the cause.

7. What should I do if the error returns after restarting?

Repeat the process checks, collect fresh Event Viewer entries, record the time of failure, and consider capturing a Process Monitor trace. If the cause remains unclear, provide the evidence to SAG Infotech support.

Conclusion

The “A Previous Instance of Genius Is Still Running” error can prevent SAG Infotech Genius from opening on a Windows Remote Desktop server, even when the cause is not immediately apparent from the process list. In the case documented here, the problem affected one user while Genius worked for others. Process checks, profile-setting comparisons, file and permission checks, and historical event-log review did not conclusively identify the root cause. A Windows system restart resolved the immediate issue. The key lesson is to investigate processes and user sessions carefully, preserve diagnostic evidence, avoid disrupting other users, and treat a successful restart as a practical resolution rather than proof of the exact underlying cause.

References

• Microsoft Learn: Understanding Access Violation (C0000005)
• Microsoft Learn: Windows startup and boot troubleshooting
• Microsoft Learn: Troubleshoot application startup failures using Process Monitor