Figuring out why FileMaker is crashing can require some sleuthing to rule out possible issues.
Basic diagnostic tests to perform when you get frequent crashes or “hangs”:
Does the crash only occur with a specific file?
Test by creating a small sample file and see if opening it and working with it also generates a crash. If it crashes too, the problem likely lies with the computer or its installation of FileMaker. If it does not crash, it becomes more likely that there is a problem with the file.
To check for possible problems on a specific computer, you may want to run a utility to check out the hard drive and also to check out the user accounts on that computer for possible problems.
To rule out some other issues with your specific computer on Windows systems,
Select Run from the start menu and type in:
Then, under the Services tab, you can stop all non-Microsoft services. If this solves the issue, then you need to look at what services you stopped and see which is one is the culprit.
What is reported when you recover the file?
The file could be damaged. Not only can file damage cause crashes, but the crashes (or forced quits after a "hang") can damage your file. You may need to test a recovered copy to see if it works without crashing.
Things to keep in mind about Recover:
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
Does it always crash when you are doing the same thing with your file?
That may point to a specific layout, script, operation that interacts with your Operating system or other applications...
In your case, since a specific script appears to be the culprit, it may be that the fix is as simple as deleting this script and creating a new copy with which to replace it.
And please note that while rare, it is not unheard of for a damaged file to apparently function normally until an OS or FileMaker update is installed and then the system exhibits signs of possible file corruption.
I've been testing all morning and have discovered that the Launch Beast Picker script is probably not the culprit. The script can be invoked and cancelled without a crash. Only when I click a button that calls the Add Beast To Item script does the crash occur. This script has 2 branches and only one of them crashes.
When I run the script in the debugger to see which script step is failing, it never crashes. It works perfectly when run from the debugger in single step mode.
I recovered the file, no errors reported. The recovered file crashes.
I used msconfig as suggested to disable all non-Microsoft services. This had no effect and it still crashes.
I tried running it in a sandbox and it crashes in the same manner.
When adding the same beast over and over it always crashes at the same number of iterations. When adding a beast whose name is longer it crashes with fewer iterations. It appears the length of the beast names are the source of the variation in the number of iterations that cause the crash. It acts just like a memory leak associated with the name field.
I'd like for someone else to try it but don't know how to upload a file here. Here's a dropbox link:
To see the crash open the file - click the Items link - click an item name - click add beast to item button - then add 35-40 beasts.
The solution is unlocked. The relevant scripts are in the Beast Picker script directory.
Am I correct, that you open and close a window each time?
I recall that scripts that open and close many windows can crash some versions of FileMaker. But that's a very hazy memory that pre-dates the Known Bugs List database that I just searched unsuccessfully.
It is probably an error in Filemaker engine (FileMaker_Pro!Draco::ScriptStep::operator). This bug can be very easily repeated. I have Windows XP and 12.0v4 Advanced.Please, TSPersonell forward it to developers.Thanks------Detail from Windbg.exe-------(1040.17fc): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling.This exception may be expected and handled.eax=00000000 ebx=089a1400 ecx=7857e40a edx=00000019 esi=00000000 edi=089a10b0eip=004e3dac esp=0012e300 ebp=0012e36c iopl=0 nv up ei pl zr na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210246*** ERROR: Symbol file could not be found. Defaulted to export symbols for FileMaker Pro.exe -FileMaker_Pro!Draco::ScriptStep::operator=+0xe050c:004e3dac 8b06 mov eax,dword ptr [esi] ds:0023:00000000=????????
Information from next similar crash (calls from Windbg):
Steve Strickland and Thomas Dohnal:
Thank you for your posts.
With your file, I am unable to replicate the issue under Windows XP and Windows 8 (VM). Here are the steps I took:
1. I opened the file using FileMaker Pro 12.0v4.
2. From the main screen, I selected the top button "Items".
3. I selected any record (Amulet of Lesser Strength or Amulet of Lesser Health).
4. I clicked "Add Beast to List". A new window opened "Select Beast".
5. I closed the window and repeated step #4.
6. I did this more than 100 times without any issue.
Do I need to add a different Beast each time, or can I select the same one. That is, should I return to the Items List and select a different Beast?
Steve Strickland and Thomas Dohnal:
I am able to replicate the problem. The issue was that I wasn't clicking "Add" in the Beast Picker. This also fails under Mac OS X 10.8.5 and Mac OS X 10.9. I'm sending your file along with your descriptions and my findings to our Development and Testing departments for review. I will keep you posted as information becomes available to me.
TSGal is this due to the repeated opening and closing of a window or does it look like something else is the cause?
Unable to speculate at this time. I'll let Testing and Development verify if it is related to the repeated opening and closing of windows.
It doesn't matter if you add the same beast to the same item, different beasts to the same item or different beats to different items.
I did notice a difference in the number of iterations that might be based on the length of the beast name where longer names crash sooner. I haven't repeated this test enough to be sure but this led me to speculate about a memory leak. In addition to wondering about opening/closing windows. I also thought about some form of mouse behavior like a ting drag or something.
A workaround idea might be to employ a self join portal with a dynamic filter that would avoid opening the beast window. The join table would still need to be opened for writing. I think I'll set up a test and see what happens.
Thanks for looking into this.
Deleting the multi-key field Beasts:Name_Input from the table eliminates the crash. I may have something wrong with it.Left ( Name ; 1 ) & ¶ &Left ( Name ; 2 ) & ¶ &Left ( Name ; 3 )Auto-index
Steve, I think the problem is not in your calculation, but maybe in corrupted index.
You can create new index (manage database - disable index - exit manage database - enable index again).
After running 100 successful iterations with the field deleted,
I added the field back to the table and the layout and used Replace Field Contents to put the multi-key text back in. It crashed after 6 iterations.
I deleted the field contents so that the field was now just an empty text field and it crashed after 6 iterations.
I deleted the field from the layout and it crashed after 6 iterations.
I deleted the field from the table and it crashed after 38 iterations.
I recovered the file with the field completely deleted. No problems were reported. All indexes reported rebuilt. It crashed after 38 iterations. This is the exact same configuration where earlier I got 100 iterations without a crash.
I pulled an archive copy from before the first crash, one that has never had a multi-key field in it and has never crashed. It crashed after 14 iterations.
I pulled an earlier version that does not use a picker window at all. It ran 100 iterations just fine.
The mystery is how can 1 picker (Items) work fine and another (Beasts) using the same layout, tables and scripts crash?
I'm going to see if I can get this interface to work as a dynamic portal filter. Modal picker windows seem to be beyond my abilities at the current time.