The FMS function LocalBigPut is causing the failure of FMS service to stop.

DrWatson says:

Application exception occurred:

App: fmserver.exe (pid=924)

When: 4/07/2006 @ 08:40:31.764

Exception number: c0000005 (access violation)

In function: LocalBigPut the fault should be this:

FAULT ->00408972 f6430a10 test byte ptr [ebx+0xa],0x10 ds:00819ee6=??

The system info:

User Name: SYSTEM

Number of Processors: 2

Processor Type: x86 Family 15 Model 2 Stepping 7

Windows 2000 Version: 5.0

Current Build: 2195

Service Pack: 4

Current Type: Multiprocessor Free

It has 4gig ram, raid discs, etc. so hw should be quite enough. There are round 70 actice users, 30 files, about 1.2 gig data, 700-900 million records, tens of thousands created/edited weekly.

Does anyone know what is that LocalBigPut function or what it should do?

Reasons for failure might be many (according the several posts e.g. in this forum and elsewhere in internet). We've tried to test every of those.

Could that simply be that FMP/FMS6 just is not enough for this amount of data/usage/filesystem?

Failure can happen during hard load of nw/server or even during low activity period. So there does not seem to be any logic...

I have a personal pet peeve against the computer and software industry in that it produces cryptic error messages which mean nothing. And THEN these various companies have the nerve NOT to provide good search features to figure out what they mean.

I spent four hours on this last night searching because of another recent post about the same LocalBigPut issue (was that you also?). The more I searched, the angrier I became. I searched FM Tech Info and Microsoft. I read all the articles about resolving error messages (and Computer Console Management and DLL errors). Lists of error codes are provided at the various websites; whether Type 1, 2, 3 or 4; Error #s etc. But it appears that this type of support is an afterthought. Maybe they figure their tech support (charged to customers) is more business-appropriate behavior.

So no, I have no answers. But I wanted you to know that I tried and that I share in your frustration over these issues.

LaRetta

No, your usage is will within FM limits.

The access violation may be a clue: do you have anz other processes running on that machine? Is OS file sharing active on the hosted files (or any parent folder of the folder where the live files are?). Is there any external backup of the hosted files?

Thanks for your quick replies & LaRetta for your efforts in searching for possible cause!

The folder is in Program Files in FM folder (in drive C together with OS). D is for swap file. Bkps are on other drive. Now we have those quite extensively - every half an hour! The crashes are not associated with the FMS bkp scripts. They happen on different times.

There are not any shared folders in C. There are not any external bkps (except on weekends when tape bkp takes place). There is one automatic shutdown during weekends (since we are running on Windows).

FMS cache is @ max 40 meg. Cache hit% is typically 99-100%. We have just recently reinstalled FMS but no help. There are about 80 processes running on the server, several of those related to newly installed HP monitoring/surveying apps.

Best practice is to dedicate the machine to running FM Server and not sharing it with anything else... especially things that deal with network and disk access.

Since you are running "newly installed HP monitoring/surveying apps" along with FMS it'd be safe to guess that that might be the cause of the problem.

It is just these difficult to diagnose service interactions that the recommended best practice avoids.

Another cause may be virus software: make sure it does not scan the hosted FMP files.

Server's only purpose is to run FMS to host FM files.

Virus scan is not scanning any .fp5 files.

Crashes started before adding those additional monitoring apps. So they haven't changed the situation.

Server is though having double nw cards (that is what should be avoided according to best practices). But the server was fine for two years! There has been an increase in no of simultaneous active users this year (50->70).

Biggest file is round 500 megs, three next ones together about the same.