This Deployment Server job can aid when troubleshooting axengine.exe crashing problems.
This is a troubleshooting step that allows us to find patterns when axengine.exe crashes or freezes.
Verify that the Deployment Solution server has an AClient or DAgent installed on itself and that it's pointing to itself.
Download the attached .vbs script.
Create a DS Console user to run the script. Open the Deployment Solution console Tools > Security.
Example: user: DShungtest pass: hungtest
Click Add button, confirm that the “DS User” is selected for Authentication
Open the rights on this user and remove all check marks. We just want a basic user.
If you aren't using Deployment Solution security, make sure that the check mark is cleared from the Enable security box.
This is a DS Console account only.It is not related to AD or the local Windows accounts.
Create a new job named hungTest.
Add a Run Script task to the hungTest job and copy the following two lines into the ‘Run this script’ field:
rem This is to test whether the DS will run a simple job exit 0
This will run a script that simply completes with a success code of 0
Choose Windows as the script operating system, then select Next
For Script Run Location, leave it On the client computer
For Client Run Environment, leave it Production – Client-installed OS(Windows/Linux/MAC OS X)
For Security context – (Windows only), leave it on Default (local system account).
For Script Options (Windows only), change it to Hidden
Right-click on the hungTest job and select Permissions.
Find the DShungtest user that was created in step 3.Check the Allow checkbox next to Schedule this job.Click the Evaluate Permissions button to verify that this is the only permission allowed.
Find the Deployment Server record in the computer’s pane of the console.Right-click and select Permissions. Highlight the DShungtest user and check Allow next to Schedule Run Script. Hit the Evaluate Permissions button to verify that this is the only permission allowed.
This will allow the user to schedule only the run script job we just created and only be allowed to run it on the Deployment Solution server.
Open and edit the RestartHungEngine.vbs script in a text editor such as Notepad.
In the variables section, modify the following;
Change the following line: credentialString = " /lu admin /lp admin" to reflect the username and password that were created in step 3.Enter the username after /lu, and the password after /lp.The user and password are case-sensitive, so it must match the user account exactly.
You may need to change jobName = “hungTest” if the job you created in step 4 was named differently
The line jobWaitSecs = 60 can be changed to the maximum number of seconds that you think a job should execute after being scheduled. A default of 60 is recommended.
The line serviceStopSecs = 120 can be changed to the maximum number of seconds that you think a service should take to stop.A default of 120 is recommended.
The line taskKillSecs = 30 can be changed to the maximum number of seconds that you think a service should take to kill, when it has not stopped properly.A default of 30 is recommended.
Save any changes made to the script
Double-click and run the .vbs script manually. Wait a couple of minutes. Note: If doing this on a 64-bit system, this needs to be run in 32-bit compatability mode. To do this, click Start > Run... > %windir%\SysWOW64\cscript.exe C:\Path\To\Script\RestartHungEngine.vbs
Check the <eXpress share>\temp folder for the EngineHang.log.Does it have output for the current state of the DS engine?
Stop the Altiris eXpress Server service. Double-click on the RestartHungEngine.vbs script (see note above for 64-bit). Wait a couple of minutes. Does it start the service and exit correctly?Are the axengineBackup.log and axengineBackup2.log files copied to the \temp folder?
Once you have verified that running the VBS script works correct when done manually you need to create a Windows Scheduled Task that will automate the process. If manually running the vbscript after going through the above steps does not produce the logs, or restart a stopped axengine or a stopped AClient service, then review the above steps so that they will work correctly.
If the VBScript is properly functioning when manually run the next step is to automate the process by using Windows Task scheduler to run this script on a schedule. This will allow you to see when the problem is occuring since Windows task scheduler can run the VBScript independent of Deployment Solution. To set this up do the following: From the Windows Control Panel on the Deployment Solution server open the Scheduling Wizard. Browse to the .vbs script, schedule it to run. Schedule it to run daily with the correct permissions, you can enter any username account that has enough rights to be able to run the script. Open the job and edit the advanced option in the schedule, select repeat task, set the minutes to be long enough to allow the script to finish if it has to wait the max amount of time (probably around 10 minutes or so) specified in the body of the script , set the duration to 23 hours 59 minutes. Save the settings and exit. Note for 64-bit: Just as running it manually, the scheduled task needs to run the script in 32-bit mode. To do this, instead of browsing to the VBscript, browse to the cscript.exe in SysWOW64, and put the full path and filename as the additional parameters (ie C:\Path\To\Script\RestartHungEngine.vbs).
Script logging details:
When the Deployment Server stops scheduling jobs the script should automatically restart the axengine and recover the server to a functioning state. The VBScript also generates its own log file called "EngineHang.log" This log file contains information of all of the details of what the VBScript is doing. Every time the script schedules the test job, when the job completes or doesn't run, as well as when services are stopped or started. This log file is useful to determine when the axengine services were either stopped (or crashed) or when the services are not responding (or hung). With this information you are able to better analyze the existing axengine.log files because you know what time frames to investigate.
The VBScript also makes a copy of the existing axengine.log and axengine2.log and renames them to axengineBackup.log and axengineBackup2.log. The reason this is done is because sometimes right after an axengine hang or crash if the axengine is restarted new log file data can overwrite the old data and the information needed to debug the process is lost. Making a copy of these logs gives you a snapshot at the exact moment that the axengine process was having problems.
When you are sending log files to Altiris Support Services, send the EngineHang.log, as well as the axengineBackup.log and axengineBackup2.log. The first log will give support information about when the problem occured (as well as any trends), and the other two logs will be a snapshot of when the problem occured.