Ghost Solution Suite

When trying to deploy the automation partition out to workstations and get them ready for an image re-deploy. I keep running into this error on random workstations when booting into the automation partition. (see attached picture)

Dagent.exe –application error

The instruction at 0x00b1f83e referenced memory at 0x010082af. The memory could not be written.

Click on OK to terminate the program.

You have to click OK and then exit out of all of the dos box windows in order to have the workstation boot back into production mode. I am seeing this more and more and it messes up the entire job when trying to deploy a image and run a configuration task after it.

How can I slove this to boot up in automation without it being a problem?

Hi,

I missed this, and to answer your question we are seeing this too.

Have you enabled DAgent logging in WinPE? My blog on this very issue has a link to a KB which will allow you to gather those logs for support. I also get a WinCrashReport dump too (though I'm not to sure how useful that is for support).

Kind Regards,
Ian./

The resolution to this will require an hotfix from Symantec. I am hoping this will be available in HF3.

Great to know. Thanks for following up on this one! I found HF2 fixed quite a few problems, hopefully HF3 will address more....

Have you tried upgrading to HF3 Bstaupp?

I have also been encountering this product crippling issue on about 20% of my systems during deployments.

When the Dagent.exe presents this behaviour it will generally do one of two things depending on what point in automation tasks the system is.

- Prevent the system from properly performing imaging tasks, often leaving the system with a Wiped MBR , thus non bootable.

- Fail to reboot at the end of an automation task, such as booting into production to configure windows. This will require systems to be manually restarted.

Things that I have done in attempt to resolve the issue.

- Install HF2 and generate new boot media.

- Install HF3 and generate new boot media.

- Install HF4 and generate new boot media.

- Disable McAfee and reinstall , then reimport the WADK components.

- Generate new boot media with McAfee disabled.

Here is the Aclient log from one of the numerous systems that have exhibited this behaviour.

[12/17/2015 00:04:39.369 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo F:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo F:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path G:\bcdinfo.cfg
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo G:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo G:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path H:\bcdinfo.cfg
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo H:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.384 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo H:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path I:\bcdinfo.cfg
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo I:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo I:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path J:\bcdinfo.cfg
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo J:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo J:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.400 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path K:\bcdinfo.cfg
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo K:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo K:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path L:\bcdinfo.cfg
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo L:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo L:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.416 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path M:\bcdinfo.cfg
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo M:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo M:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path N:\bcdinfo.cfg
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo N:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo N:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.431 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path O:\bcdinfo.cfg
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo O:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo O:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path P:\bcdinfo.cfg
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo P:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo P:\bcdosdevice.cfg file not found
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Check if bcdinfo.cfg file is present on path Q:\bcdinfo.cfg
[12/17/2015 00:04:39.447 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Q:\bcdinfo.cfg file not found
[12/17/2015 00:04:39.463 1888 1] RequestWorkToDo.cpp : CRequestWorkToDo Q:\bcdosdevice.cfg file not found
 

Hi wmyhers1,

Please open a case with Symantec Support and get it linked to case #09148269. It's a known issue but support need more log and crash dump combos to track this down. To do this they will ask you to enable agent logging in automation and ask you to collect dagent.exe process dumps to go with it (full dump via taskgr just when dagent.exe crashes).

Kind Regards,
Ian./

Hi ianatkin,

I would like to collect some more data before I contact Symantec again with this issue. Is there a variable that I can use with the aclient.inp that would allow me to save the logs with the computername in the filename? This would allow me to grab data in a more effective manner.

EG if the computer name in the GSS console is PC01 i would have the client save the log to M:\Dagent_Automation_Logs\PC01_Aclientlog.txt 

Thanks,

Hi wmyers1,

I've posted up an article recently to help collect logs on this so you can push them to Symantec support 

https://www-secure.symantec.com/connect/articles/configuring-winpe-automatically-collect-crash-dumps

Kind Regards,
Ian./

Any update on this as i am seeing it with HF5 as well.

It's still not resolved. Contact support with the logs from your setup (modifying your automation environment to collect them as I describe in the link above).

I am seeing this still being a problem after upgrading to GSS 3.1 MP1. However the error is slightly different:

dagnet.exe - Application Error

The instruction at 0x00E3C46A referenced memory at 0x0050A5D8. The memory could not be read.

Click the OK to terminate the Program

If you close out it and re-run the runagent.bat, it will reload dagent.exe and re-connect to the GSS server and re-start the ghost task. Most of the time the job will finish up. However this is a problem not knowing which workstation fail and you have to go around to a group of them that have failed and re-run the dagent.exe in order to finish it all.

Brad

This should be resolved in 3.1 MP2 which will be released nexrt week (on Monday the 13th).

We've been testing the automation agent destined for MP2 fo a few weeks now and have not seen a single agent crash.

Kind Regards,
Ian./

Great! I will look forward to downloading it on monday and getting it setup. This has been a problem for a while and I hope they got it sloved!

Brad

2 major issues with automation were addressed with this update, the automation agent crashing and the silent termination of the agent.    

https://support.symantec.com/en_US/article.DOC9335.html  for info on MP2.   

Thank you to every one who helped collect dump files for us while we were working on this issue. 

Is this the correct URL: https://support.symantec.com/en_US/article.DOC9335.html

That link above did not really go anywhere.

Brad