marko

a2service.exe application error

Recommended Posts

Hello

I've had two separate instances of this application faulting since yesterday, once on my laptop yesterday evening and once on my desktop pc this morning - both machiines are running W10 Home fully patched and EAM 2018.4.0.8631 (although the laptop is currently on the EAM beta update channel while testing a fix for issues in this thread https://support.emsisoft.com/topic/29510-right-click-context-scan-causing-explorer-to-hang/)

In both cases, the a2service fault caused Windows to hang completely and I had to hold the power button down to turn the machines off.  I did manage to open Task Manager before the system locked up completely, and I noticed in the Details tab that there were two separate a2service.exe entries, both of which had a status of Suspended.

I've attached the error logs from Windows Event Viewer in case these are of any help in identying the problem.

a2service fault laptop.txt

a2service fault desktop.txt

Share this post


Link to post
Share on other sites

I am seeing a lot of application hang errors (especially for SyncBackPro.exe on the laptop, but also for explorer.exe) as well as a bunch of system errors in the Event Logs. FRST only shows the last 10, so I don't know how long it's been happening (at least since early May). It's possible that something else is wrong, however I can't be certain from what the logs show. The logs don't really show anything abnormal, other than the errors recorded in the Event Logs.

Considering that the backup software is hanging more frequently than anything else, would it be possible to try uninstalling it temporarily and see if the issues go away?

Share this post


Link to post
Share on other sites

The errors with SyncbackPro all occurred within a few minutes of each other on 12th May afternoon and were caused by me testing some cloud backup settings - I'm certain these aren't the cause of the a2service errors causing explorer to hang.

 

Share this post


Link to post
Share on other sites

There's still the explorer.exe hangs that didn't happen on the 12th on the laptop, and the odd permissions errors in the Event Logs on both computers.

The symptoms seem more like a compatibility issue between two anti-virus softwares, but you don't have more than one anti-virus installed, which is why I suspected backup software as the next most likely culprit.

Does switching to the Delayed feed in Emsisoft Anti-Malware and allowing it to downgrade to version 2018.2 resolve the issue with a2service.exe crashing? Here's how to do that:

  1. Open Emsisoft Anti-Malware.
  2. Click on Settings in the menu at the top.
  3. Click on Updates in the menu at the top.
  4. On the left, under Update Settings, click on the box to the right of Update feed and select Delayed from the list.
  5. Click on the Update now button on the right side.

Share this post


Link to post
Share on other sites
8 minutes ago, GT500 said:

There's still the explorer.exe hangs that didn't happen on the 12th on the laptop, and the odd permissions errors in the Event Logs on both computers.

The symptoms seem more like a compatibility issue between two anti-virus softwares, but you don't have more than one anti-virus installed, which is why I suspected backup software as the next most likely culprit.

the only explorer errors I can see, other than the ones caused by a2service, were on 1st and coincided with the install of W10 Spring update, and a couple of others that were caused by a2start

re the permission errors, I assume you're referring to the DCOM errors )ID 10016) - I've always had these and I just ignore them - info here https://support.microsoft.com/en-gb/help/4022522/dcom-event-id-10016-is-logged-in-windows-10-and-windows-server-2016

18 minutes ago, GT500 said:

Does switching to the Delayed feed in Emsisoft Anti-Malware and allowing it to downgrade to version 2018.2 resolve the issue with a2service.exe crashing? Here's how to do that:

  1. Open Emsisoft Anti-Malware.
  2. Click on Settings in the menu at the top.
  3. Click on Updates in the menu at the top.
  4. On the left, under Update Settings, click on the box to the right of Update feed and select Delayed from the list.
  5. Click on the Update now button on the right side.

I could try this on one of the machines but I'm not sure how effective this will be given that the a2service errors aren't that frequent.  Would it not be more effective to stay on the existing feed and somehow collect more detailed logs or dumpfiles when and if it happens again

Share this post


Link to post
Share on other sites
On 5/18/2018 at 8:33 PM, marko said:

Would it not be more effective to stay on the existing feed and somehow collect more detailed logs or dumpfiles when and if it happens again

Debug logs may very well be helpful, however if you can't predict when it will happen then you could burn up a lot of hard drive space waiting for it to happen. The logs can of course be manually deleted, so if you want to turn on debug logging and wait for the issue to happen then I will post instructions in a separate post. The instructions are long, but not complicated, so they are far more painful to read than to follow.

That being said, what might be more helpful than debug logs would be a memory dump of a2service.exe when it crashes. If there's some sort of dialog to notify you of the crash, then the process a2service.exe should remain in memory until you close the dialog, and you can use something like Process Hacker (this is an advanced process management and debugging tool that some of our developers and malware analysts like) to save the process's memory to a file. All you have to do is run Process Hacker with Administrator rights, find a2service.exe in the list of running processes, right-click on it, and select Save dump file.

Important note: The Self-Protection in Emsisoft Anti-Malware will freeze Process Hacker (and possibly more than that) if you try to save a memory dump of a2service.exe without first turning off the Self-Protection. To turn it off, open Emsisoft Anti-Malware, click on Settings in the menu at the top, and the option will be on the left side near the top.

image.png
Download Image

Share this post


Link to post
Share on other sites

Here's the instructions for debug logs:

  1. Open Emsisoft Anti-Malware.
  2. In the 4 little gray boxes at the bottom, move your mouse into the one that says Support, and click anywhere in that gray box.
  3. At the bottom, change the option for Debug logging to Enabled for 1 day (or 7 days, or whatever you think will be necessary to give you enough time to wait for the crash to happen).
  4. After that, close the Emsisoft Anti-Malware window.
  5. Reproduce the issue you are having (wait for the crash to happen).
  6. Once the crash has happened, open Emsisoft Anti-Malware again, and click on the gray box for Support again.
  7. Click on the button that says Send an email.
  8. Select the logs in the left that show today's dates (if you try to send too many logs, then we may not receive them).
  9. Fill in the e-mail contact form with your name, your e-mail address, and a description of what the logs are for (if possible please leave a link to the topic on the forums that the logs are related to in your message).
  10. If you have any screenshots or another file that you need to send with the logs, then you can click the Attach file button at the bottom (only one file can be attached at a time).
  11. Click on Send now at the bottom once you are ready to send the logs.

Important: Please be sure to turn debug logging back off after sending us the logs. There are some negative effects to having debug logging turned on, such as reduced performance and wasting hard drive space, and it is not recommended to leave debug logging turned on for a long period of time unless it is necessary to collect debug logs.

Edited by GT500
Changed a few steps to make more sense in this instance.

Share this post


Link to post
Share on other sites

As a followup, the debug logs are located in the following folder (assuming Windows is installed on your C: drive):

C:\ProgramData\Emsisoft\Logs

To get there quickly, hold down the Windows logo key on your keyboard (usually found between the Ctrl and Alt keys), and tap the R key to open the Run dialog. Paste the following into the Run dialog, and click OK.

%AllUsersProfile%\Emsisoft\Logs

You can delete these logs while Emsisoft Anti-Malware is running, and while debug logging is turned on. The names have numeric codes for the date and time Emsisoft Anti-Malware started saving them, so it's easy to figure out which is the oldest and which is the newest. The format of the date/time code is YYYYMMDDHHmmSS where YYYY=year, MM=month, DD=day, HH=hour (in 24 hour format), mm=minute, and SS=second.

Share this post


Link to post
Share on other sites

Thanks for the suggestions - I'm running EAM on the beta channel and I've disabled self protection.  I've also turned debug mode on for a day at a time, and will provide logs if and when the problem happens again.

If the same thing does happen again, I may not be able to get a dump file from Process Hacker as when it happened last time I couldn't open any other applications as the computer had completely locked up - time will tell.

Share this post


Link to post
Share on other sites

If you can't use Process Hacker to get the memory dump, then ProcDump can be used to automatically save a memory dump when a process terminates. You have to run it from an elevated (run as Administrator) Command Prompt, and execute the following command after using the "CD" command to navigate to the folder where procdump64 is located:

procdump64.exe -ma -t a2service.exe

If I remember right, it automatically saves the memory dump in the same folder that procdump64 runs out of, and it gives it the same name as the process it was monitoring.

Share this post


Link to post
Share on other sites

ProcDump needs to be run before the crash happens, so if you just go ahead and start it using the command I posted above and leave it running, it will save its memory dump when the crash happens. If you want to you can just make a batch file with the command in it, put it in the same folder as procdump64, and then run the batch file as an Administrator and minimize the window so that you don't have to manually run ProcDump via the Command Prompt every time you want to start it.

Share this post


Link to post
Share on other sites

OK. Hopefully ProcDump will be able to save the memory dump for you, but if not then I can post instructions for setting up a way to force a BSoD and memory dump with a keyboard shortcut.

Share this post


Link to post
Share on other sites

I've just had another instance of a2service.exe faulting and again it caused windows to lock up completely.

Unfortunately, I do not have a dump file from ProcDump as the application faulted during logon (after the desktop loaded) and I hadn't had chance to start ProcDump before it happened.

I was running EAM in debug mode so perhaps the logs will show something - please let me know if you want them, and how best to send them.

I've attached the Windows Event Viewer log for info.

P.S. I forgot to mention that I'm on the beta feed so was updated to build 8668 a couple of days ago.

a2service error 27052018.txt

Edited by marko
included comment about build number

Share this post


Link to post
Share on other sites

It happened again this morning - turned my computer on, entered my windows password, waited for desktop to finish loading, then started the ProcDump process to monitor a2service.exe, opened my browser and my email client - a minute or two later, everything locked up again.

A slight difference this time is that a Microsoft Windows message appeared after a couple of minutes saying that Windows was not responding (see attached) - I had to capture this with my phone camera as I wasn't able to use a screenshot tool as everything was locked up.

I waited about ten minutes to see if Windows would recover itself but to no avail so had to power off by holding the power button down.

This time, there is nothing in Event Viewer to say that a2service.exe had faulted, but ProcDump tried to create a dump file so I am assuming that a2service did cause the problem.  Unfortunately, the dump file that ProcDUmp created is empty (0 bytes) - see attached dumpfile for reference.

I do have EAM debug logs for this so again, plese let me know if you want them and how best to send them.

Windows error.jpg
Download Image

a2service.exe_180528_074531.dmp

Share this post


Link to post
Share on other sites
14 hours ago, marko said:

Unfortunately, the dump file that ProcDUmp created is empty (0 bytes) - see attached dumpfile for reference.

That is unfortunate, since there's no data in it for us to analyze. We'll have to force Windows to save a full memory dump.

Is this a desktop or a laptop? Do you use a USB keyboard?

Share this post


Link to post
Share on other sites
17 minutes ago, GT500 said:

That is unfortunate, since there's no data in it for us to analyze. We'll have to force Windows to save a full memory dump.

Is this a desktop or a laptop? Do you use a USB keyboard?

It's a laptop using the integrated keyboard

Share this post


Link to post
Share on other sites

The batch files in the ZIP archive at the following link can be used to enable a feature in Windows that will allow you to force your computer to crash and save a memory dump simply by pressing a keyboard combination:
https://www.gt500.org/emsisoft/PS2_Crash_On_Crtl_Scroll_Lock_Batch_Files.zip

Simply do the following:

  1. Download and open the ZIP archive.
  2. Double-click on the Enable_Crash_on_Ctrl_Scroll_Lock_PS2 batch file.
  3. A black window will open and inform you that it is checking for administrator rights, and that it may take a moment.
  4. When asked you if you want to allow the Windows Command Processor to make changes to your computer, please click Yes to continue.
  5. A new black window should open, and should close again relatively quickly. Once the new black window closes, it is finished.
  6. Restart your computer so that the changes take effect.

After following those instructions, you can hold down the right Ctrl key on your keyboard and tap Scroll Lock twice to force your computer to crash and save a memory dump. This memory dump should contain enough information for us to get an idea of what is going on.

Share this post


Link to post
Share on other sites

@marko - you might need to check whether your "integrated keyboard" actually is a PS/2 one - Control Panel - Device Manager should tell you.  Also, if your keyboard (like mine) has no Scroll Lock key, the process is more complicated.

Share this post


Link to post
Share on other sites
12 minutes ago, JeremyNicoll said:

@marko - you might need to check whether your "integrated keyboard" actually is a PS/2 one - Control Panel - Device Manager should tell you.  Also, if your keyboard (like mine) has no Scroll Lock key, the process is more complicated.

Thanks Jeremy - yes I checked that this morning and it's a standard PS/2 keyboard.

My scroll lock key is accessed via Fn + ScrLk so I have to press Ctrl and Fn+ScrLk twice to trigger a dump but I've tested it and it works fine, although interestingly it only works using the Ctrl key on the right of the space bar - it doesn't work if I use the one on the left - go figure.

Just waitng for another lock up now so I can generate a dump file.

a2service crashed again first thing this morning before I'd had chance to add the registry key and it's been fine since !

 

Share this post


Link to post
Share on other sites
2 hours ago, marko said:

... interestingly it only works using the Ctrl key on the right of the space bar - it doesn't work if I use the one on the left - go figure.

The two Ctrl keys have different keyboard codes, and Microsoft used the codes for the one on the right rather than the one on the left. There's a procedure for changing the keys, but it requires registry editing and looking up keyboard codes.

Share this post


Link to post
Share on other sites

Hi

Sorry to 'Thread Crash' but FYI I am seeing a very similar problem with EAM for Server.  Errors are as shown below.  The symptoms seem identical and it's on a server so potentially quite serious.

Error

Application Error

Tue May 22 17:37:44 2018

1000

Faulting application name: a2service.exe, version: 2018.4.0.8631, time stamp: 0x5ae8995d Faulting module name: ntdll.dll, version: 6.2.9200.22376, time stamp: 0x5a90c271 Exception code: 0xc0000374 Fault offset: 0x00000000000da535 Faulting process id: 0x3a0 Faulting application start time: 0x01d3f18e954cfd11 Faulting application path: C:\Program Files\Emsisoft Anti-Malware\a2service.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 7360d968-5dde-11e8-9462-6805ca172017 Faulting package full name: Faulting package-relative application ID:

 

 

 

Information Application Popup Tue May 22 05:56:04 2018 26 Application popup: smss.exe - Bad Image : C:\PROGRAM FILES\EMSISOFT ANTI-MALWARE\a2hooks64.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. Error status 0xc0000428. 

Thought an uninstall and re-install of EAM might help.

 

Share this post


Link to post
Share on other sites
3 hours ago, pieronip said:

Sorry to 'Thread Crash' but FYI I am seeing a very similar problem with EAM for Server.  Errors are as shown below.  The symptoms seem identical and it's on a server so potentially quite serious.

Any possibility of a memory dump from a2service.exe when it crashes? We have instructions for configuring WER to save automatic crash dumps at the following link (be sure to enable full crash dumps):
https://helpdesk.emsisoft.com/en-us/article/204-how-do-i-configure-automatic-crash-dumps-in-case-of-application-failures

Share this post


Link to post
Share on other sites
2 hours ago, GT500 said:

Any possibility of a memory dump from a2service.exe when it crashes? We have instructions for configuring WER to save automatic crash dumps at the following link (be sure to enable full crash dumps):
https://helpdesk.emsisoft.com/en-us/article/204-how-do-i-configure-automatic-crash-dumps-in-case-of-application-failures

This is a production server so the opportunities are a bit limited.  I shall try to get this for you however.

 

Chers.

 

Paul

Share this post


Link to post
Share on other sites
5 hours ago, pieronip said:

This is a production server so the opportunities are a bit limited.  I shall try to get this for you however.

If a reboot is out of the question, then feel free to try the method using ProcDump detailed above, and quoted below:

 

On 5/23/2018 at 9:05 AM, GT500 said:

If you can't use Process Hacker to get the memory dump, then ProcDump can be used to automatically save a memory dump when a process terminates. You have to run it from an elevated (run as Administrator) Command Prompt, and execute the following command after using the "CD" command to navigate to the folder where procdump64 is located:

procdump64.exe -ma -t a2service.exe

If I remember right, it automatically saves the memory dump in the same folder that procdump64 runs out of, and it gives it the same name as the process it was monitoring.

 

On 5/23/2018 at 10:14 PM, GT500 said:

ProcDump needs to be run before the crash happens, so if you just go ahead and start it using the command I posted above and leave it running, it will save its memory dump when the crash happens. If you want to you can just make a batch file with the command in it, put it in the same folder as procdump64, and then run the batch file as an Administrator and minimize the window so that you don't have to manually run ProcDump via the Command Prompt every time you want to start it.

 

Share this post


Link to post
Share on other sites

I had another lock up this morning - there were no entreies in Event Viewer saying that a2service.exe had faulted, but ProcDump had created another empty dump file so I suspect a2service did cause the problem.

So, I manually invoked a blue screen using the Ctrl and SclLck keys but it didn't create a dump file - event viewer shows Error 161 - Dump file creation failed due to error during dump creation - see attached log file from Event Viewer.

I'm not sure what's going on as I tested the dump file creation a couple of days ago and it worked fine.

After a reboot, I tried again as a test and I get the same error 161.

Any ideas ?

dump file failure.txt

Share this post


Link to post
Share on other sites

After the test dump was created did you move the MEMORY.DMP  file elsewhere?  Or alternatively do you have the option set (in W8.1 it's at: Control Panel - System - Advanced - Startup & Recovery - System failure - Dump file - Overwrite...) that will allow Windows to overwrite that file when it tried to take a new dump?

Share this post


Link to post
Share on other sites
15 minutes ago, JeremyNicoll said:

After the test dump was created did you move the MEMORY.DMP  file elsewhere?

I'm not sure of the relevance of the question, but the test dump I created the other day was just that, a test, so I deleted it.

16 minutes ago, JeremyNicoll said:

Or alternatively do you have the option set (in W8.1 it's at: Control Panel - System - Advanced - Startup & Recovery - System failure - Dump file - Overwrite...) that will allow Windows to overwrite that file when it tried to take a new dump?

it's set to overwrite if a file exists

image.png.dae31e3f2b59e7955d18ae0496a4e93f.png
Download Image

Share this post


Link to post
Share on other sites

The reason I asked both questions is that if you hadn't had overwrite set, and had left the old dump in place, you wouldn't expect Windows to take a new dump.

Share this post


Link to post
Share on other sites

You could look at: https://support.microsoft.com/en-au/help/130536/windows-does-not-save-memory-dump-file-after-a-crash

but I don't think that'll help much - if the test dump you created previously was properly taken.  I also see you have the type of dump that will be taken set to "automatic memory dump" - it needs to be "complete memory dump" (at least on W8)  - though I can't quite see why that would stop a dump from being taken.  And your paging file needs to be on the same disk as Windows is, and (despite what the URL above says) it needs to be at least 257 MB larger than your system's amount of RAM.

Share this post


Link to post
Share on other sites
40 minutes ago, JeremyNicoll said:

The reason I asked both questions is that if you hadn't had overwrite set, and had left the old dump in place, you wouldn't expect Windows to take a new dump.

ah sorry - I see now - I must be getting old - thanks

34 minutes ago, JeremyNicoll said:

You could look at: https://support.microsoft.com/en-au/help/130536/windows-does-not-save-memory-dump-file-after-a-crash

but I don't think that'll help much - if the test dump you created previously was properly taken.  I also see you have the type of dump that will be taken set to "automatic memory dump" - it needs to be "complete memory dump" (at least on W8)  - though I can't quite see why that would stop a dump from being taken.  And your paging file needs to be on the same disk as Windows is, and (despite what the URL above says) it needs to be at least 257 MB larger than your system's amount of RAM.

I'm using W10 with 8GB RAM and the page file is set to be automatically managed by Windows so I assumed the page file size would increase automatically as needed, including when it needs to create a dump file.

image.png.85a15634cc508ca7324dfe2fefa9f568.png
Download Image

Perhaps GT500 or someone else from Emsisoft can confirm whether my settings are ok or not ?

Share this post


Link to post
Share on other sites

I think you need to preallocate a paging file that's at least 8449 MB in size (that's 8*1024 + 257).  The thing is, normally when any OS starts dumping, it's in a mess.  Usually by then normal OS internal actions are suspended.  I would not expect the logic that's capable of expanding a page file in normal operation to be capable of, or even allowed to, execute when a full system dump is being taken.   The paging file is where the dump is actually put.  It's not until you reboot afterwards that the dump is copied from the paging file into MEMORY.DMP.

The RAM + 257 MB thing is explained at https://support.microsoft.com/en-gb/kb/2860880

Share this post


Link to post
Share on other sites

Well I just unchecked the box that says Automatically manage page file size, then rebooted, then checked it again and rebooted and now I can force a memory dump again - very odd but hopefully now it'll work when I get another lock up.

image.png.a30f729de33ddb082cb60567ef3d04f8.png
Download Image

Thanks for the info/comments about the page file size - it does say on the page you link to 'By default, page files are system-managed. This means that the page files increase and decrease based on many factors, such as the amount of physical memory installed, the process of accommodating the system commit charge, and the process of accommodating a system crash dump' so I assumed this meant my settings were ok ?

GT500 - could you confirm please whether I need to change the dump file setting from Automatic Memory Dump to Complete Memory Dump, and could you also confirm whether my page file size and/or settings are sufficient to allow whichever dump file is needed - thanks

Share this post


Link to post
Share on other sites

You need to read the bit of that MS KB page entited "Automatic memory dump", where - yes - it does say that the pagefile will be automatically sized to suit a dump... but the "Automatic memory dump" option is "intelligent".  It sizes the page file for a dump that does not aim to contain all possible detail, on the assumption that normal users (by which I guess they mean programmers of simple application programs) will not want a complete /system/ dump.   But in your case it's a /system/ problem, and it's a full system dump that Emsisoft are likely to need.  So you need "complete memory dump" and a bigger pagefile.

Read the paragraph starting "Kernel memory crash dumps..." and bear in mind it's no use relying on Windows to slowly make the page file bigger so that one day in future the paging file will be big enough.  You need to make the page file big enough at the start so that it will hold the dump you need when the problem happens.

Share this post


Link to post
Share on other sites

Also... there's no guarantee that any of these changes will /actually/ make the dump happen properly.  We don't know why it's not happening properly.   Maybe there's a bug in that part of the OS.

Share this post


Link to post
Share on other sites

I don't need to read it tbut thanks for your suggestion - unfortunately I don't have the time to read all the ins and outs of that KB

Whether it's 'likely' that they need a Complete dump is supposition on your part, but if they do then you'll be proved right, but until GT500 gets back to me to confirm I'll leave it as it is for now rather than changing things if they don't need changing

Share this post


Link to post
Share on other sites
9 hours ago, marko said:

... I assumed the page file size would increase automatically as needed, including when it needs to create a dump file.

Once the BSoD happens, Windows will no longer scale the size of the pagefile. Disk I/O during a system crash is considered unsafe, which is why the memory dump is written to the pagefile rather than directly to the disk.

 

8 hours ago, marko said:

so I assumed this meant my settings were ok ?

Your settings are default, and should be OK in most circumstances, however there are times when Windows is a little funny about virtual memory management and may not increase the size of the pagefile to be able to contain everything that is in RAM. You can try playing around with the manual setting and see if setting the minimum to the same as the amount of RAM you have and the maximum to 1.5 times the amount of RAM you have makes any difference. Feel free to change it back when done trying it out.

 

8 hours ago, marko said:

GT500 - could you confirm please whether I need to change the dump file setting from Automatic Memory Dump to Complete Memory Dump

That depends on whether or not the relevent data ends up in the dump automatically created by Windows. There are certainly times where it doesn't, and complete memory dumps are needed. Using the Complete Memory Dump option is the easiest if you don't want to try it again, but of course produces a much larger file that you then have to compress and upload somewhere you can share with us (preferably via private messages, as memory dumps can contain anything that was in memory when they were saved).

Share this post


Link to post
Share on other sites

I've had two more crashes since last posting, once on Saturday morning, and another this morning - my impresssion is that when it happens, it is shortly after login.

Unfortunately, each time it's happened, I've been unable to create a dump file.

ProcDump tries to create one but it just seems to not finish - it does create a new dump file but it is 0 bytes each time.  This morning I noticed in the Command Prompt window that it said 'Unhandled C000041D Dump 1 initiated C:\ProcDump\ a2service.exe_180604_102447.dmp'.

I've tried to manually initiate a crash dump from the keyboard when the a2service crash happens but it just goes to the blue screen with 0% progress then restarts without creating the dump file - Windows Event Viewer shows an error in volmgr when this happens - see attached file.

I've set my system up to create a Complete memory dump and changed my page file settings to be 8500MB min to 12000MB max, and I am able to manually initiate a dump file from the keyboard when the system isn't hung - it's just when it has hung that it doesn't work.

I've also checked dump file creation using the Crash Dump Test in WhoCrashed and it works fine so this suggests my settings are fine.

One thing I did notice is that, after restarting the machine following this morning's crash, EAM debug logs seem to have reverted to Disabled although I'm fairly certain it should still be Enabled for 1 day - I may be mistaken but it's difficult to be sure as if the user turns debug logging on or off in the gui, this action isn't written to the forensic log.

I also noticed that there are only two debug logs (one for a2service and one for a2guard) created this morning at 10:23 (I started the machine at 10:22), but it didn't create one for a2start so I assume this means a2service crashed before a2start could load.  This also implies that debug logging was Enabled when the crash happened, yet it showed as Disabled after restarting following the crash.  I've attached these two debug logs in case they shed any light on the matter.

volmgr error.txt

EAM debug logs 20180604102332.zip

Edited by marko
typo

Share this post


Link to post
Share on other sites

It's curious that it restarts after the blue screen, whether or not any dump is taken.

> I've tried to manually initiate a crash dump from the keyboard when the a2service crash happens ...

I realise this is not a useful post... but the trigger is not meant to manually initiate a crash dump.   It is meant to trigger a BSOD.   The expected/normal treatment of any BSOD, by the OS, is to take the configured type of dump.    The problem you have isn't the trigger, but the dump mechanism, presumably because of that  volmgr  thing.  I don't know what that is (can't see your attached files), but does googling that produce any useful suggestions?

Share this post


Link to post
Share on other sites
13 minutes ago, JeremyNicoll said:

It's curious that it restarts after the blue screen, whether or not any dump is taken.

> I've tried to manually initiate a crash dump from the keyboard when the a2service crash happens ...

I realise this is not a useful post... but the trigger is not meant to manually initiate a crash dump.   It is meant to trigger a BSOD.   The expected/normal treatment of any BSOD, by the OS, is to take the configured type of dump.    The problem you have isn't the trigger, but the dump mechanism, presumably because of that  volmgr  thing.  I don't know what that is (can't see your attached files), but does googling that produce any useful suggestions?

thanks for the clarification - ok, so it's creating the blue screen but not the crash dump.

It's odd that a dump file is generated when initiating a BSOD from the keyboard or WhoCrashed when the system isn't locked up, but it doesn't create one when I trigger the BSOD when the system is locked up

I've already tried googling the volmgr error but couldn't find anything definitive

Share this post


Link to post
Share on other sites

> It's odd...

The trouble is, dumping an OS that's not well is never guaranteed to work because you need some parts of the OS to be working still.   I used to work on IBM mainframes where the last-ditch diagnostic collection mechanism was something called a 'standalone dump'.  The dump program was booted over the top of the dead system and it, rather than the OS, would then dump all of RAM and the linked contents of page files.  The management didn't like standalone dumps being done because they could delay an attemped restart of the dead system by 20-30 minutes.   

Share this post


Link to post
Share on other sites

The plot thickens - I just tried to generate a dump file via the keyboard as a test (again), and this time the BSDO appeared showing 0% then the pc rebooted and no dump file was created (just as it does when I do it after an a2service crash) and I had the same volmgr error in event viewer, so it seems to be completely random - sometimes it will create a dump file and sometimes not, regardless of whether the system has hung or not.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.