0

In our program we are using a web service to pull back data from a third party into our program.

Ever since we updated to Delphi XE from Delphi 2009, Windows server 2003 users are receiving the following error message when making a SOAP call to the web service.

enter image description here

msvcrt.dll on Server 2003 does not have the procedure _ftol2_sse which is now being called for some reason..

I know this procedure was not being called when we had our source code on Delphi 2009 because I don't get this error on Windows server 2003 when running those builds.

Is this feasible? Could a change in the IDE affect which dll procedures are being called? Does anyone have any insight or ideas on how I might track down or fix this error?

Thanks

Trevor
  • 16,080
  • 9
  • 52
  • 83
  • Earlier today, you thought it was caused by XMLDocument. Are you sure now it is the SOAP call? http://stackoverflow.com/questions/12900487/alternative-to-txmldocument – GolezTrol Oct 16 '12 at 20:07
  • Well I'm having a real hard time getting to the bottom of the problem. This error at least popped up after some XMLDocument calls however when I commented out these lines the error still crept up until I had commented out almost every line. Once I thought I had found the line where it occurred I commented out that line and brought back the rest and it still showed up. So it just seems to occur from multiple places in the program. This web service call is another area of the program where it occurs.. So I just thought I would mention it. I'm wondering if a change to xe could have caused it. – Trevor Oct 16 '12 at 20:16
  • Do you know how to use debugging tools? Especially breakpoints and stepping through the code? It would help yourself (and us) if you could actually trace down the line that causes the error. – GolezTrol Oct 16 '12 at 20:21
  • Yeah, the problem I'm having with that is that I can't reproduce the error in my development environment its strictly a windows 2003 server issue. – Trevor Oct 16 '12 at 20:31

1 Answers1

2

This is the third similar question you have asked on this topic. I'll attempt to give you some background information and help you work out what is going on.

First of all it's important to know that msvcrt.dll is a system component. It is not the MSVC runtime. It is supplied as part of Windows. Back in the bad old days, in the mid-90s, a lot of devlopers assumed that the MSVC6 runtime was always available. And they neglected to install that runtime as part of their program's installation. This occasionally caused trouble when the install program happened to find a machine without MSVC6.

The MSVC team moved to differently named runtime DLLs, msvcrt70.dll, msvcrt80.dll and so on. And they educated the developers that installing the MSVC runtime should be part of all MSVC application's installation programs.

But the Windows team wanted to help out legacy apps that had installers that assumed MSVC6 runtime was available. So they took the MSVC6 runtime under their control and started shipping it with Windows. I think this started around the time of Windows 2000 or XP.

The point I am trying to make is that msvcrt.dll is a system DLL over which you have no control. In your previous questions you have described your attempts to modify that DLL. Don't do that.

Now, from what I can glean, the version of msvcrt.dll that shipped with 2003 server does not export a function named _ftol2_sse. Hardly surprising since SSE floating point was not widely available back in the days of 2003 server. Clearly something in your system is resulting in an attempt to import _ftol2_sse.

You should be able to work out what is provoking this by using Dependency Walker. Use the functions on the Profile menu to start your application and study closely the logs. You should be able to see the chain of events that lead to an attempt to link to _ftol2_sse.

I'd be surprised if any of the Windows code linked to msvcrt.dll. That library is provided purely as a prop for legacy apps that link against MSVC6. But you never know.

Also try loading your executable in Dependency Walker. Look at the list of imported DLLs. Check to see if msvcrt.dll is in the list. If so, see what functions your executable imports, and if _ftol2_sse is in that list. If so then you'll be able to find it somewhere in the Delphi source code.

From the various similar sounding reports on the web I suspect that the problem you face is benign. Many of the people reporting the same issue can OK the dialogs and have their program continue without problem. This suggests that you can simply suppress the error reporting and so solve your problem. Use the SetErrorMode function to do so. You want to include the SEM_FAILCRITICALERRORS flag.

Be aware that SetErrorMode has a rather perverse interface. Almost all code that I have ever seen uses it incorrectly. Including the code in the Delphi RTL, and so many of the commonly used Delphi third party libraries. Raymond Chen, as usual, explains how to use it correctly.

Could switching compilers provoke the behaviour change? Certainly they could. Either the library code that you are using is implemented differently. Or perhaps the error mode is somehow different at the crucial moment.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Does this look right? dwMode := SetErrorMode(SEM_FAILCRITICALERRORS); try //error prone code here finally SetErrorMode(dwMode); end; Do you know how I would ignore SEM_NOGPFAULTERRORBOX and SEM_FAILCRITICALERRORS in the same call? – Trevor Oct 16 '12 at 21:42
  • I would do this at startup: dwMode := SetErrorMode(SEM_FAILCRITICALERRORS); SetErrorMode(dwMode or SEM_FAILCRITICALERRORS); Does it help? – David Heffernan Oct 16 '12 at 21:50
  • Yeah sorry is there away when you call dwMode:= SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); ? I'm not sure how to combine the two in delphi. – Trevor Oct 16 '12 at 21:54
  • | is logical or in C++. So that's the or operator in Delphi. Use the code in my previous comment. Does SetErrorMode solve your problem? – David Heffernan Oct 16 '12 at 21:58
  • Oh yeah that makes sense.. Great I'm testing it right now, just waiting to hear back. I was still getting this (non System) error "The specified procedure could not be found, ClassID: {88D96A05-F192-11D4-A65F-0040963251E5}" I'm hoping that extra flag will take care of that error message.. – Trevor Oct 16 '12 at 22:01
  • You need to get server 2003 at your fingertips. On a vm perhaps. – David Heffernan Oct 16 '12 at 22:03
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/18133/discussion-between-trevor-and-david-heffernan) – Trevor Oct 16 '12 at 22:06
  • Thanks for answering my question with all the additional information. I think I may be on to what caused the issue when updating from delphi 2009 to delphi xe. When I do I'll post an answer below explaining what happened. – Trevor Oct 18 '12 at 22:50
  • 1
    Super old but saved my day at work. Thanks for the DependencyWalker tip. Found out `AVIFIL32.dll` was importing `VSCRT.dll` that was using `_ftoll2_sse`. Since I use the X-Vid codec for my videos I could exclude this dependency from my installer and then it worked. – agrum Apr 29 '15 at 18:16