GP 2013R2 crashes randomly for the past few weeks due to KERNELBASE.DLL fault

(0) Share

Report

Posted on by Beat Bucher GP Gee...

28,058 Moderator

Hi,

This is a rather strange case which I could find many reports in the community, but no solutions posted so far.. It started with some users reporting it last week and I could trace back the occurence as far as April 24th on our RDP server (W2012 RDS published apps, no full desktop access) and also one local GP client user on Win7 that reported it

I couldn't find any commonality as for what could lead to the crash, as it happens randomly and no one really could tell me if it was happening only after doing certain actions in GP. I even had users reporting GP crashing while they had left their computer and when came back, the dreadfull pop-up was on the screen (App Crash for Dynamics.exe from Windows).

In the Event Log I could find this, which repeats itself many times during the day, as we serve about 10-12 GP users on a permanent basis from that RDS server :

Faulting application name: Dynamics.exe, version: 12.0.323.0, time stamp: 0x5564de96
Faulting module name: KERNELBASE.dll, version: 6.2.9200.22141, time stamp: 0x58f11bee
Exception code: 0x4000001f
Fault offset: 0x0008a424
Faulting process id: 0xf18
Faulting application start time: 0x01d3eb8baec0c178
Faulting application path: C:\Program Files (x86)\Microsoft Dynamics\GP2013\Dynamics.exe
Faulting module path: C:\Windows\SYSTEM32\KERNELBASE.dll
Report Id: 4626fcad-5781-11e8-9460-0050568d46d5
Faulting package full name:
Faulting package-relative application ID:

One forum reply suggested to delete the user profile from the server, which I tried and it didn't took an hour before it happened again..

There had been no updates (windows or Office) applied on the server for months, so it wasn't something we could roll-back, and in fact we ran a scheduled Windows Update last week-end in the hope the some 30 packages (many offices) would cure the problem, but alas, no hope.

Based on an old blog post from Microsoft for a similar issue with GP 2010, I tried to capture a memory dump from the crashing Dynamics.exe process and it generated a 700mb large .dmp file, but I have no clue on how to analyze the file.. So I can 't really get more details what's causing KERNALBASE.DLL to tear down the GP process.

https://blogs.msdn.microsoft.com/developingfordynamicsgp/2012/05/31/running-dynamics-gp-2010-ax-2012-and-sl-2011-on-the-same-machine/

Any help would be really appreciate, as users starts to get frustrated (some clients crash several times in the day)..

*This post is locked for comments

I have the same question (0)

All responses (15)

Answers (1)

Heather Roggeveen 9,146 on at

Like (0)

Report

Hi Beat

I am having the exact same issue at one of my sites at the moment. Just a recent occurrence and I end up with CBPAY batches that I need to fix data on.

We also tried to recreate the profile but the error has happened since.

My client has a terminal server and SQL Server hosted in Azure.

The other clues in an old link I have been using to try and troubleshoot is to recreate the Reports.dic

That is my next step.

My client is version 2015 R2.

So hopefully we get some responses on this.

The article I have been using is this one: community.dynamics.com/.../239914

Cheers

Heather

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Thank you Heather,

I don't think it's a REPORTS.DIC issue, as we serve many users thru RDS published apps and only a few of them are experiencing crashes.. it's not consistent and it would eventually mean that the crash happens when you want to print a report, which isn't the case all the time.

Today we had several more crashes, but one in the event log caught my attention, as it is similar to one reported in a different post :

https://community.dynamics.com/gp/f/32/t/110463?pi53330=1#responses

Application: Dynamics.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at <Module>.TNTsend_message(HWND__*, EVENT*)
at <Module>.?A0xb912366b.send_E_INIT(Byte*)
at <Module>.dtw_powerup(HINSTANCE__*, Byte*)
at <Module>._WinMainCRTStartup()

Was this reply helpful? Yes No
Derek Albaugh on at

Like (1)

Report

I had a support case last year with just this exact error, but unfortunately the partner went dark before we verified a resolution. In my case, it also had to do with a terminal server environment, occurred randomly and was worse for one user but all experienced it to some extent.

I guess if I were to troubleshoot this type of issue, I'd start with some of these first to try and identify where the issue may lie, so to focus further troubleshooting in a specific direction, such as:

1. We sometimes see issues with RemoteApp/published apps that we don't see in a regular terminal server or local install environment, so similar to 3rd party products, I'd be curious if we installed a 'clean' install of Dynamics GP, with no 3rd party products or customizations/vba, then not going through a remote app or published app setup, just launch GP directly, connect to the same GP databases and see if this issue can be re-created or not. This would at least help rule out the issue being something in the databases/data themselves.

2. At that point, you could add back any third-party products or customizations, one-by-one to see if the crashing came back after any of these. If so, then you'd have your potential cause. If not, then it could be a matter of the Dynamics GP code being damaged or corrupted in some way, or the published app environment.

If it was specific to one or two users, I'd focus more on the user's profile, files in their TEMP directory that Dynamics GP adds and removes each time they login to the application, things like that.

It also doesn't sound like it's any specific process being performed in GP when the crashing occurs, as you mentioned users have left their workstations idle and came back to this type of error.

Other things we've seen causing Dynamics GP to crash:

--Dynamics.exe not configured as an exclusion in Data Execution Prevention (DEP)

--Antivirus application scanning files in Dynamics GP folder/forms and reports dictionary files/Dynamics.exe.

--Reports or forms dictionary files corrupted - this can be true even if the user isn't actively printing a modified report or opening a modified window.

--Users using Dynamics GP denied access to a file or registry location (ProcMon is good for detecting this)

I guess I would start with the above and then see if any of these help point you into a specific direction for further troubleshooting, if it doesn't find the cause of the issue outright.

Thanks

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi Derek,

Thanks for the extensive reply.. I've actually opened a case yesterday with our partner, in the hope that someone from Microsoft could jump in and debug the .dmp files I have on hand from some of the crashes.. I was told by our developpers in house that without the source code, there is little chances that the dump file is going to reveal anything useful..

I'm going to check the various suggestions (like DEP & AV) to make sure they can be excluded from the cause. REPORTS.DIC is going to be my next step and see if I can recover from a previous 'good known' version.

I almost positively can exclude permissions issues, as nothing had changed on the server since several months, the last windows patches were done in February or March, and they are done in a controlled way.

And yes, though several users are affected, it seems to target more some users as others, but that may just be pure bad-luck as they are more 'heavy' GP users in general.

Thanks again for chiming in, and I'll keep the thread alive until we found the culprit. Several similar posts have been left un-answered and it's frustrating in such cases.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

So yesterday I was trying to repoint the DYNAMICS.SET file for a local GP client to a copy of the REPORTS.DIC that was put locally too.. Somehow I thought it was a success because the user reported no crash for the entire day..

Based on this, I replaced the shared REPORTS.DIC file on the GP server (where all launch files are pointing to) by a backup copy in the hopes the RDS server's GP client would stop crashing too.. but alas, this morning a 8:33 a user reported a GP crash..

So my next step would be to investigate the DEP & AV path..

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

So,

Another few days went by and I had enabled DEP and added DYNAMICS.EXE to the exclusion list, but yesterday another crash occured on the server.. there was only one because our main office was closed for a holiday, so I'm going to watch it for another day, but it's unlikely a (re)solution to our problem.. my next step will be to run a repair on the GP client.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Update on the situation..

Today the 1st thing in the morning I did was installing a local GP client for that user that had crashed 10 times yesterday on the TS server.. since nothing seemed to help in any ways.

Less than an hour into working with the brand new GP client (never had before any local instance before) on this Win7 system, GP crashed.

I tried different things again, all of the above mentioned, but the rebuild of the dictionaries for the customized reports & forms.. We have a lot of modules installed and many customized objects in GP (over 100), so it's going to be a lengthy process to identify which one might be corrupted.

After the 6th crash this morning, I started to rebuild the REPORTS.DIC.. I'm curious how long it's going to last until next crash..

It might seem a strange coincidence, but since I had moved that user from the TS server to a local client, I didn't had a single crash on the TS side for today.. So the next thing I'm going to try is to delete that user's GP account and re-create it.

Was this reply helpful? Yes No
Derek Albaugh on at

Like (0)

Report

When you installed Dynamics GP directly on the Win7 workstation, which had never had GP installed on it, did you add any 3rd party products or customizations to it?

If so, I would've recommended installing a 'clean' install without any 3rd party products or customizations to see if you can re-create the issue of GP crashing. If so, then you would know it isn't anything to do with those products or customizations, but if it didn't crash, then you'd need to add those back one-by-one until the crash occurs again.

You actually don't even need the forms or reports dictionary files as Dynamics GP will work without them, though you may get 'unable to find dictionary' messages if the user attempts to pull a modified form or report.

Another test would be to move any forms/reports dictionary files local, to rule those out. One of the risks if these dictionary files are on a shared directory, is that they can frequently become corrupted if more than one user access the dictionary files/reports at the same time or make changes while someone is in the dictionary.

I do agree that it'd be useful to try and determine whether the issue is user-specific or not, as you mentioned that once you moved this user off the TS, you haven't had a crash as of yet.

Thanks

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi Derek,

Yes, when I did the full GP client install, it was with all the 3rd party modules.. because this is an AP/AR user and needs the full set of our Mekorma MICR tools.. But I could give it try to remove any 3rd-party products..

As for the customization's, there are tons of reports that where modified (and on purpose) over the years, and not putting them basically renders the GP useless for us.. Not really an option. But as I said, I've already rebuilt the REPORTS.DIC & the client keeps crashing anyway. Going to try the FORMS.DIC next and also re-create the GP user..

Was this reply helpful? Yes No
Mick Egan 3,561 on at

Like (0)

Report

Beat,

Try the following:

Control Panel\All Control Panel Items\System >> Advanced System Settings >> Advanced >> Performance >> Settings >> Data Execution Prevention.

If the "Turn on DEP for essential Windows programs and services only" is selected, then ignore as problem is elsewhere.

If "Turn on DEP for all programs and services except those I select", there are 2options, 1: Add Dynamics.exe as an exception, or 2: select the first option "Windows programs and services only", re-boot the computer after either change.

Took a long time to find this one.

Mick

Was this reply helpful? Yes No