Nav2009 SP1 Intermittant Classic Client Crash

TimSimmonds

Hi All,

We’re just working through a technical upgrade of our 7 business databases from v3.60b to Nav2009 SP1 (release build).
We’re running the SQL Client version on SQL2008 SP3, in a thin client, Windows Server 2003 SP2 environment on XenServer.

We are upgrading in stages and have completed first one. It’s been running for a couple of weeks and a financial month end has been processed without any major problems, apart from the fact that the client crashes intermittently, maybe two times a day for some users.

There is nothing obvious that is causing the crashing. The event log does not reveal any useful info. Users can be running a posting routine or something as simple as opening up a location card form. The effected users simply restart the Client and continue where they left off.

No hotfixes seem relevant to our issue.

As we have not upgraded all databases as yet, we are running both client versions which perhaps is the problem?? :?

Any help or pointers would be appreciated. Although this isn’t a major issue it gives us an uneasy feeling to continue with our upgrade/rollout with known glitches.

Thanks in advance...

ara3n

are the two clients sharing the same zup file?

TimSimmonds

Hi ara3n,

Sorry, I didn't think anybody had responded... we are giving up hope on this one . Microsoft are not eagerly willing to help because we have only done a technical upgrade and not converted all our objects also.

I was hopeful your query would be the answer to our problem, but a test on this didn't cause a crash. Our users may be using the original 360 zup file though. Have you seen any direct issues yourself with this?

We have moved slightly forward in our attempts at a fix:
• Removed the 3.60 Client altogether from our Citrix Build – this hasn’t made any difference
• Put the latest Client build onto our Citrix Servers (31839) - this hasn’t made any difference

We did apply a MS fix for error reporting which meant we do get at least some error logging although our tech guys are seeing some strange behaviour where the error reporting tool kicks in (dw20.exe) . It tells us that a file will be included in the data sent to Microsoft (navinfo.txt). This file is stored in the users roaming profile, however, it gets deleted almost instantly – sometimes before finsql.exe is restarted by dw20.exe, sometimes after. To get around our tech guys are currently using the .Net System.IO.FileSystemWatcher class to monitor our Citrix Servers for the navinfo.txt file, then use the .net smtp client to send a mail with the file attached. This is working well and we are now getting notifications for each crash, along with the navinfo.txt file.

There does not seem to be any correlation between the events, so they appear at different times, different servers, different users and the navinfo.txt file contains different information in it (from what I can see different codeunits, forms, calls to functions etc...but nothing consistant).

Our tech guys have also managed to attach WinDbg to a number of crashed processes now and generate dump files for them. After analyzing each there doesn’t seem to be anything common, other than the DLL’s, most common being the Navision SQL Server Driver, ndbcs.dll.

The plot thickens....

David_Singleton

TimSimmonds wrote:

No hotfixes seem relevant to our issue.

How so? There are definitely builds that crash like this. though normally not a simple crash, its normally because of over load due to bad reads. Still it could be the version.

What could be happening is that you have a query that is taking along time, maybe because of a clustered seek due to a Dynamic Cursor, so the client eventually just gives up and dies.

Are you seeing performance issues since the Executable upgrade?

TimSimmonds

David Singleton wrote:

[Are you seeing performance issues since the Executable upgrade?

Thanks David for your reply. We are considering performance to be the issue as restarting the client allows the user to continue processing. However we haven't noticed any significant degregation of performance since the upgrade.

We have applied the latest hotfix (build 31839), on advice from Microsoft, but it hasn't helped.

On occasion the user has reported SQl messages on screen and we have been able to SQl profile them, whilst they repeat the error. The SQL profiles show incomplete prepared statements as though it gave up half way through creating it!! - the sql error presented to the user would be something like "unclosed quotation mark after character string"
Another SQL errror has been "error converting data type varchar to numeric" but we have been unable to profile this. Again, restarting the Client allows the user to carry on processing..all very odd!.

Any further help...or suggestions would be most appreciated.

David_Singleton

Unfortunately Microsoft no longer support mixed versions, (i.e. old objects on new executable) even 5.00 objects on 5.00sp1 executables is unsupported.

My gut feeling is that because of this there will not be the attention to backward compatibility that Navision has been famous for over the years. Therefor you need to go through code and find areas where the old code is incompatible with the new executables.

ara3n

It's interesting that I was at NAV R2 release Event in Toronto and the MS representative told a customer that MS only will support the executables and not the db if you do exe upgrade.

TimSimmonds

David Singleton wrote:

Therefor you need to go through code and find areas where the old code is incompatible with the new executables.

I think we were looking for a quick solution. We have a lot of bespoke development so this could take a while... although it is looking like the only option if we can't get further support from Microsoft.

Surely though, if all objects compile under Nav2009 and we have done full functionality tests without problem you would think that our code was ok??

David_Singleton

ara3n wrote:

It's interesting that I was at NAV R2 release Event in Toronto and the MS representative told a customer that MS only will support the executables and not the db if you do exe upgrade.

OK, well that is a change, not much better, but at least they will now support the executables.

How do they do this? Will they require you to set it up in Cronus and have you replicate the error there?

David_Singleton

TimSimmonds wrote:

Surely though, if all objects compile under Nav2009 and we have done full functionality tests without problem you would think that our code was ok??

Definitely I would NOT assume that.

You can no longer assume that code that works on one set of executabels will work correctly on newer executables. This is why Microsoft no longer support mixed objects/executables.

DenSter

David Singleton wrote:

How do they do this? Will they require you to set it up in Cronus and have you replicate the error there?

That's exactly how they do it, have been for years. If you can't, or won't they will help as much as they can, but if you can't reproduce it in a Cronus database, it's technically not a NAV problem.

David_Singleton

DenSter wrote:

David Singleton wrote:

How do they do this? Will they require you to set it up in Cronus and have you replicate the error there?

That's exactly how they do it, have been for years. If you can't, or won't they will help as much as they can, but if you can't reproduce it in a Cronus database, it's technically not a NAV problem.

So has anything changed then really? Basically if they don't support a modified database then what's the difference.

DenSter

They support modified databases, but in order for Microsoft to acknowledge that it is a Microsoft problem, you have to be ready to prove that it is, indeed, a problem that is present in a standard Microsoft product. The only way to really conclusively do that (according to their logic) is to show that the problem exists in an unmodified database. Surely you don't expect Microsoft to support every piece of crappy custom code.

I'm sure that this is because they have had countless problems that turned out to have been caused by modified code. It's a drag to have to recreate the issue in a Cronus database, but sometimes you'll also see that it is your own code.

TimSimmonds

Just to report back that we eventually did solve our issues.

We luckily did get some help from Microsoft Dev Team and the R2 version was found to run fine without having to do a full object upgrade.