Skip to main content

Problem signature:

 

Problem Event Name: BEX64

 

Application Name: fmeworker.exe

 

Application Version: 2018.7.34.18310

 

Application Timestamp: 5b03ca3e

 

Fault Module Name: StackHash_761b

 

Fault Module Version: 0.0.0.0

 

Fault Module Timestamp: 00000000

 

Exception Offset: 000007fe7ee0124b

 

Exception Code: c0000005

 

Exception Data: 0000000000000008

 

OS Version: 6.1.7601.2.1.0.256.48

 

Locale ID: 5129

 

Additional Information 1: 761b

 

Additional Information 2: 761b8286f685b3d40ac141f6068cfeb6

 

Additional Information 3: c89c

 

Additional Information 4: c89cd562f414498be5c93ca53b0dbbf9

 

 

I am running Windows 7, ArcGIS 10.6, ArcGIS Pro 2.2, 64 bit Python extension, FME 32 and FME64

I have reinstalled, repaired and upgraded everything.

I have read all the old notes about clashes with 64 and 32 bit.

This crash happens with no FME errors when I simply generate a new workspace. If I close the system crash box (pasted above) the workbench carries on as normal, until it crashes after running, but again I can simply dismiss the box and it appears to have finished normally.

This does not happen if I open 32 bit FME.

On an identical setup on my laptop (but Windows 10) I do not get the crashes.

I am running FME(R) 2018.0.1.1 (20180615 - Build 18312 - WIN64) with Windows 7 Professional on a Dell Laptop. I am getting "Error running translation." for the most simple translations from MIF to KML.

 

Occasionally I get Translation was SUCCESSFUL but if I run it again immediately without making a single edit it fails again.

 

Do you think I should try 32 bit FME instead?

 

 


I am running FME(R) 2018.0.1.1 (20180615 - Build 18312 - WIN64) with Windows 7 Professional on a Dell Laptop. I am getting "Error running translation." for the most simple translations from MIF to KML.

 

Occasionally I get Translation was SUCCESSFUL but if I run it again immediately without making a single edit it fails again.

 

Do you think I should try 32 bit FME instead?

 

 

Hi @giarcnomis - I think it would be a good idea to submit the log file to our support team (or paste it here if possible). I'm sure there must be something else in the log that explains why the translation has failed. A quick guess would be a lack of disk space/memory, or a permissions problem writing to a particular folder. Anyway, I think the log would be useful as a first step to diagnose your issue. Use safe.com/support if you want to submit it in private.

 


Hi @kimo - does this occur on every new workspace, regardless of format? I run 32 and 64-bit on Windows 7 without issue, but I don't have the same ArcGIS software installed, so I can't say for sure whether that is the problem or not. I have heard of a couple of problems with the ArcObjects Geodatabase R/W with ArcGIS Pro 2.2. Is that the format you are using in these workspaces?

 


Hi @kimo,

I'm wondering if this is linked to this problem here that was reported for Windows 7: https://knowledge.safe.com/articles/63592/fme-exe-has-stopped-working-after-updating-windows.html

Perhaps check to see if you have these window updates installed: KB4056894 and/or KB405689

If so, you may want to try the two solutions suggested in the article to see if it fixes the issue with FME 64-bit.

- Andrea


Hi @giarcnomis - I think it would be a good idea to submit the log file to our support team (or paste it here if possible). I'm sure there must be something else in the log that explains why the translation has failed. A quick guess would be a lack of disk space/memory, or a permissions problem writing to a particular folder. Anyway, I think the log would be useful as a first step to diagnose your issue. Use safe.com/support if you want to submit it in private.

 

Hi @Mark2AtSafe, I had an FME support team member Nampreet look at my workspace and log files.

 

I have 202 Gb free disk space.

 

I just ran a quick one now so I could share it with you using the 32 bit FME.

 

As far as I can tell it isn't a problem with my data.

 

I think you may be right about it being a permissions problem.

 

mif6ogckml.fmw

 

log.txt

 

 


I don't have the problematic Windows updates listed but I have upgraded
to 10.6 WITHOUT installing the 64bit geoprocessing patch after
installing the 64 bit python extension. Installing the patch fixed the crashing. https://support.esri.com/en/download/7579

What is surprising is that we need to keep installing the patch after
every update! The patch has versions dating back to 10.1. The problem
has been surfacing since 2009 according to the datestamps on
Knowledgebase. Thanks to all the support on this problem, it has been a
lot of time on fruitless searching.


Hi @Mark2AtSafe, I had an FME support team member Nampreet look at my workspace and log files.

 

I have 202 Gb free disk space.

 

I just ran a quick one now so I could share it with you using the 32 bit FME.

 

As far as I can tell it isn't a problem with my data.

 

I think you may be right about it being a permissions problem.

 

mif6ogckml.fmw

 

log.txt

 

 

Hi. Well I looked at the log file and I can see the workspace finished reading data without problem. With no blocking transformers in the workspace it would already be writing data by the time the reader finished (in fact I believe it would have already written all the data except the final feature). So I doubt it's a permissions issue, but you could obviously test that by writing to a different folder. My other suggestions are to try running the workspace with feature caching turned off, in case it's the caching rather than the writing that is causing the problem. Also try using the Writer Redirect parameter (in the Navigator window, under Workspace Parameters > Translations > Reader/Writer Redirect) to see if the translation will complete if the data isn't being sent to the writer (try Redirect to FFS File and Redirect to Inspector). I know these don't solve the issue, but to be honest, at this point I think we'll need a developer to step in and help diagnose the exact cause. But if we can narrow down where the problem occurs it will help speed up that process. I've been in touch with Nampreet and he knows what is going on. If you can send your results to him as well as here, then he can talk to the developers directly if necessary.

 


Hi. Well I looked at the log file and I can see the workspace finished reading data without problem. With no blocking transformers in the workspace it would already be writing data by the time the reader finished (in fact I believe it would have already written all the data except the final feature). So I doubt it's a permissions issue, but you could obviously test that by writing to a different folder. My other suggestions are to try running the workspace with feature caching turned off, in case it's the caching rather than the writing that is causing the problem. Also try using the Writer Redirect parameter (in the Navigator window, under Workspace Parameters > Translations > Reader/Writer Redirect) to see if the translation will complete if the data isn't being sent to the writer (try Redirect to FFS File and Redirect to Inspector). I know these don't solve the issue, but to be honest, at this point I think we'll need a developer to step in and help diagnose the exact cause. But if we can narrow down where the problem occurs it will help speed up that process. I've been in touch with Nampreet and he knows what is going on. If you can send your results to him as well as here, then he can talk to the developers directly if necessary.

 

Hi @Mark2AtSafe I have run your suggestions and it resulted in a ffs file being produced each time it was Redirected.

 

When I Inspect the FSS file with FME Data Inspector 2018.0 it records the following errors:

 

 

The FFS file `C:\\Users\\scraig\\Documents\\FME\\FFS\\Test1.ffs' failed the CRC check. It is corrupt, and cannot be read

 

Failed to specify the feature index as constraints on the reader

 

The FFS file `

C:\\Users\\scraig\\Documents\\FME\\FFS\\Test1.ffs' failed the CRC check. It is corrupt, and cannot be read

 

 

When set to Redirect to Data Inspector it fails to open.

 

A recover file is also placed into the Workspaces folder.

 

See attached.

 

mif7ogckml.fmw

 

rtsison.txt

 

ffsison.txt

 

ffs.txt


Hi @Mark2AtSafe I have run your suggestions and it resulted in a ffs file being produced each time it was Redirected.

 

When I Inspect the FSS file with FME Data Inspector 2018.0 it records the following errors:

 

 

The FFS file `C:\\Users\\scraig\\Documents\\FME\\FFS\\Test1.ffs' failed the CRC check. It is corrupt, and cannot be read

 

Failed to specify the feature index as constraints on the reader

 

The FFS file `

C:\\Users\\scraig\\Documents\\FME\\FFS\\Test1.ffs' failed the CRC check. It is corrupt, and cannot be read

 

 

When set to Redirect to Data Inspector it fails to open.

 

A recover file is also placed into the Workspaces folder.

 

See attached.

 

mif7ogckml.fmw

 

rtsison.txt

 

ffsison.txt

 

ffs.txt

@Mark2AtSafe I have now done a clean re installation of FME 2018.1 but I'm still getting Error running translation.

 

A windows error report was produced the first time I ran the new 2018.1.

 

 

I have received the following windows message.

 

 

Files that help describe the

problem:

 

C:\\Users\\scraig\\AppData\\Local\\Temp\\WER5772.tmp.WERInternalMetadata.xml

 

C:\\Users\\scraig\\AppData\\Local\\Temp\\WER7677.tmp.appcompat.txt

 

C:\\Users\\scraig\\AppData\\Local\\Temp\\WER77FE.tmp.mdmp

 

Read our privacy statement

online:

 

http://go.microsoft.com/fwlink/?linkid=104288&clcid;=0x0409

 

If the online privacy

statement is not available, please read our privacy statement offline:

 

C:\\Windows\\system32\\en-US\\erofflps.txt

 

 

Attached are the temp files referred to in the windows message and the files from running the translation.

 

wer7677tmpappcompat.txt

 

wer5772tmpwerinternalmetadata.xml

 

parks-mif2ogckml.fmw

 

parks-mif2ogckmllog.txt

 


FYI for those of you looking for the patch for 10.6.1, it looks like they merged desktop/server into one: https://support.esri.com/en/download/7639


Reply