Issue with Automatic Scheduled Report Printing

The issue you're experiencing with the Smart Vue application not printing reports when the screen is locked or the user is logged off could be related to how the application interacts with the Windows printing system under those conditions. Here are some potential areas to investigate:

1. Application Behavior: Since the application does not use Windows Task Scheduler, it might be dependent on the user session being active to execute the print command. Some applications require an active user session to function correctly, especially for tasks like printing.
2. User Session Requirements: Many applications, especially those that run in the user context, may not have the necessary permissions or resources to execute tasks when the user is logged off or the session is locked. This could explain why the printing works when you are logged in but fails otherwise.
3. Service Permissions: Even though you granted "Allow log on as service" rights, the application may still need to run in the context of an active user session to access the printer and execute the print job.
4. Print Spooler Service: Ensure that the Print Spooler service is set to start automatically and is running correctly. If the service stops unexpectedly, it could affect printing tasks.
5. Driver Issues: Although you've reinstalled and updated the printer driver, ensure that the driver is compatible with your application and the Windows version. Sometimes, using a generic driver can resolve issues related to specific application compatibility.
6. Scheduled Task Alternative: If possible, consider configuring the application to use Windows Task Scheduler or another method that can run tasks independently of user sessions. This might require changes in how the application is set up or additional features from the vendor.
7. Logs and Error Reporting: Check if the application has any logging features that might provide insight into what happens when it tries to print while the session is locked or logged off.

Since the application behavior is not typical for standard printing tasks, reaching out to the application's support team may also provide specific guidance based on its design and functionality.

References:

• Troubleshoot known issues for printing
• Troubleshoot printing issues caused by Print Spooler service not running

Good morning Krunal Patel,

The file path: %userprofile%\AppData\Local\VirtualStore\.... confirms that Smart Vue is a legacy application trying to write to C:\Program Files (x86), which requires Administrator privileges. Because it lacks them, Windows UAC redirects the configuration file (SmartVueClient.ini) to the user's virtual store. When you log off, the user registry hive is unloaded, and processes running under that user context are terminated. Even when the screen is simply locked, modern Windows power management can suspend user-mode applications that rely on active desktop rendering (GDI objects) to generate reports.

Your solution requires decoupling the application from the interactive user session and fixing the configuration fragmentation caused by UAC virtualization.

First, you must resolve the split configuration issue. Because the application is currently reading from the VirtualStore, it is isolated to that specific user's interactive session. You need to move the SmartVueClient.ini file from %userprofile%\AppData\Local\VirtualStore\Program Files (x86)\Thermo\Smart-Vue\ directly into the main application directory at C:\Program Files (x86)\Thermo\Smart-Vue\. After moving the file, right-click the Smart-Vue folder in Program Files, select Properties > Security, and grant Modify permissions to the Users group. This ensures the application can read and write its schedule configuration directly in the system path without triggering VirtualStore redirection, making the configuration accessible to the application regardless of who is logged in or which context it runs under.

Second, you need to ensure the application persists when the user logs off. The "Allow log on as service" right you granted is ineffective because the executable is not registered as a Windows Service. The most robust fix for a legacy application like this is to use Windows Task Scheduler as a persistent launcher. Create a new Task with the Trigger set to "At Startup". In the General tab, ensure you select the specific user account that has the printer mappings configured, and crucially, select "Run whether user is logged on or not". This setting forces the application to run in Session 0, a non-interactive background session that survives log-offs.

Thanks VPHAN for your response.

I tried steps suggested by you but still print was not coming at scheduled time.

I had not tried solution of automatic logon because even user logged on but screen is locked than also report not printed.

The fact that the print job fails specifically when the screen is locked (even while the user is logged in) confirms that the issue is not just about permissions, but about GDI (Graphics Device Interface) Rendering.

Your HP LaserJet MFP M128 is a "Host-Based" printer (sometimes called GDI or UFR). Unlike enterprise printers that interpret PCL or PostScript commands on their own internal CPU, Host-Based printers rely on the Windows Desktop Window Manager (DWM) and the computer's CPU to rasterize the print job into an image before sending it down the wire.

Here is the technical failure chain:

1. Locked Screen: When you lock Windows 10 (Win+L), the OS suspends the interactive display driver and the GDI rendering context to secure the session.

App Trigger: Smart Vue triggers the print job at 10:00 AM.

Rendering Failure: The printer driver attempts to grab the current display context to generate the page image. Because the screen is locked, the handle to the display device is null or suspended. The job fails silently because there is no "canvas" to draw the report on.

Since the application vendor confirmed they rely on the OS (and likely this specific rendering method), you have two solutions. You should try them in this order.

Solution 1: Switch to the HP Universal Print Driver (PCL6)

If you can force the printer to use a PCL (Printer Command Language) driver, the rendering workload moves from the Windows OS to the Printer's hardware. This bypasses the need for an unlocked, active screen.

Download the HP Universal Print Driver (UPD) for Windows - PCL 6 from the HP website.

Install the driver. When prompted, select "Traditional Mode" and manually select the port your current M128 is using (usually USB001 or a WSD port).

Once installed, go to Printers & Scanners, select the new HP Universal Printing device, and set it as the Default Printer.

Test the lock scenario. If the M128 supports PCL translation (some lower-end models do not, but many do), the report will print even while the machine is locked.

Solution 2: The "Dark Kiosk" Configuration (Workaround)

If the M128 is strictly Host-Based and rejects the PCL driver, you physically cannot print while the workstation is locked. You must configure the machine to stay logged in and unlocked, but turn off the monitor to simulate a "secure" state.

You must undo the "LockWorkStation" script I previously mentioned and apply this configuration:

1. Enable Secure Auto-Logon (Essential) You must use the Sysinternals Autologon utility (from Microsoft) to save the credentials in the LSA secret store. This ensures the PC automatically logs into the correct user context after a reboot or power failure.

Download/Run Autologon.exe.

Enter the credentials for the user with the printer mapping.

Click Enable.

2. Prevent "Sleep" and "Lock" You need the computer to be fully awake, just with the monitor powered down.

Go to Settings > System > Power & sleep.

Set Screen to: "Turn off after 5 minutes".

Set Sleep to: "Never".

Go to Settings > Accounts > Sign-in options.

Under Require sign-in, change the setting to Never.

3. Disable the Screen Saver Lock

Type "Screen Saver" in the Start menu to open Change Screen Saver.

Ensure "On resume, display logon screen" is Unchecked.

4. Physical Security Since the computer will technically be unlocked (just with a black screen), anyone who wiggles the mouse will see the desktop. You must rely on the physical security of the laboratory (locked door) rather than the Windows lock screen.

Thanks for Help. I had found that issue is with application and same was accepted by application support person this time i saw all my observation to him and they agree.

Thanks again for help.