Access violation in ntdll.RtlUnwind when try to save document with "doc" format

I Use Aspose.Words with Com Interop and Delphi Program.

I make a model document with at least one field or a table.

I Open this document but when i save it again with another name for example but with especially doc format then the application freeze or under Delphi debugger make an access violation exception.

Excuse for my bad English

Best Regards Eric.

Hi Eric.

Would you send us the code fragment and the document, if only it’s possible? It would be better to make a minimal sample on which the behavior is reproduced.

Thank you.

Thank’s for your answer, here is joined a project for test

don’t forget readme file.

Best Regard Eric.

We examined your project and composed minimal equivalent sample in a scripting language to check COM interoperability. Now it doesn’t reproduce the issue. I’ll perform some additional tests, maybe even in Delphi. Most probably it is related to the environment.

Thank you.

could you reproduce the error with the executables files which I sent with projet

Can you specify me your script language used

Thank

Eric

Which .net framework version does you use for test?

I have noticed some differences beetwen witch kind version was running

When I use the Framework v1.1.4322, some documents save operation work fine, for bigger one I obtain an EOleException (in delphi) with this message ‘overflow or underflow in arithmetic operation’

I join you the .config file for my executable file so you can try it easely with differents versions of framework.

I join you an other document that will not work with .net framework 1.1 and 2.

Thanks a lot for your help.

Have a nice day

Eric.

Thank you for additional info. I’ll take a look.

I tested on both 1.X and 2.X. Your compiled applications terminate without any warning and output files of zero length are created. I used VBScript to reproduce the issue. And plan to check on Delphi 7, the version you use.

Hello.

I made a script which performs the same operations on the documents as your Delphi project. See the attachment. The script does the following:

  • Loads the source file
  • Enumerates all bookmarks giving their names in message boxes
  • Enumerates all form fields giving their names in message boxes
  • Saves the document with different name

VBScript doesn’t reproduce this issue. No exception is thrown.

I installed Delphi 7 and compared what happens in it.

There I see that exception raises from the following code called

indirectly from document.Save() method:

Status := Dispatch.Invoke(DispID, GUID\_NULL, 0, InvKind, DispParams,

Result, @ExcepInfo, nil);

if Status <> 0 then DispatchInvokeError(Status, ExcepInfo);

In debug mode with breakpoints it is not thrown, so I was able to pass

saving and got an output file. No data loss was detected, output is

good. This is an issue related to Delphi OLE Dispatch implementation mechanism.

At least one workaround follows from the fact that the exception is raised only when document is saved in

“doc” format.

See also the article describing probable difficulties with COM clients:
https://docs.aspose.com/words/net/supported-platforms/#com

For this issue new entry in defect database was created: 3174.

We plan to make effort on that in the future, but don’t promise any dates.

Regards

Hello Viktor,

Thank you very much for all help that you brought to me. I finally found a solution, it is necessary to disable the Floating Point Exceptions by using Set8087CW($133f)

Have a nice day

Eric

Great to hear you found a solution.

Does it mean Aspose.Words does something with floating point numbers when saving as DOC which triggers and exception and that somehow screws things so badly that we get access violation etc messages?

Do you think something needs to be fixed in Aspose.Words or is it purely a Delphi instability issue and a generally accepted fix?

Hello Roman,

Excuse me for ma late answer,

I am not really certain but yes I think that there remains a problem in the treatment of the files “DOC.” in Aspose.words

There is no exception when using Microsoft developemment tools because the default value of the FPUCW is different

but sorry I do not know this subject very well and not enough time to search.

Best Regards Eric.