[jfreeman]

I have a network with Windows Server 2003 (without Winfax) and all clients have XP SP3. Windows Firewalls are all off, there is a Sonicwall Hardware Router/Firewall on the network. I successfully uninstalled Winfax Pro 10.02 from each client and installed 10.03 on each followed by the 10.04 patch to network the program. I made a dedicated client the host machine and successfully connected all 6 clients to it. I can send faxes from all clients. All works fine except when more than one unread fax is received at the host, upon clicking OK on a client to view the messages (one client is set up to automatically receive), an error occurs on the client involving wfxctl32.exe (microsoft error) and the program crashes. This might also occur when clicking “Show All Messages”. As recommended in another post, I downloaded winfax tools 111 but when I attempt to run the log and phonebook repair tool on the host I receive a “Run Time Error ‘339’ Component ‘mscomctl.ocx’ or one of its dependencies not correctly registered: a file is missing or invalid”. I downloaded the VB 6.0 Common Controls from microsoft, ran it, but the error recurs (this may be a separate problem). The tool runs fine on the other clients. Any suggestions as to what I have done wrong or what I can do to fix both issues?

Thank you

[JohnD]

I’m not sure about the 1st problem your experiencing with 2 or more unread faxes, but lets first try to repair the 2nd OCX error problem so you can try the rebuild.

First check to see if the file MSCOMCTL.OCX is found on the system where this is not working. Usually it should be in the WindowsSystem32 folder.

If you have this file on your system, then you may need to manually register with REGSVR32 by following these steps:

Click on start menu-> Run

Type :

Regsvr32 c:windowssystem32mscomctl32.ocx

and press enter.

(replace the path above to match where the mscomctl32.ocx file was found on your system)

[jfreeman]

Thank you for your reply. That file is missing from that particular computer but present on another workstation. How do I fix it?

[JohnD]

The easiest method would be to copy the file from a working machine (with the same operating system) and copy it to the WindowsSystem32 folder.

Then perform the steps listed above to register the file.

also , is this thread similiar (at all) to the problem you are encountering?
viewtopic.php?f=18&t=1205

[jfreeman]

Yes, the thread you pointed me to is similar. When I updated the network I archived all logs from the clients and started with a clean slate. The test faxes contained a CSID with a comma. In re-looking again, the problem will occur with just one fax in the receive log that contains a comma in the CSID. Quite a frustrating problem since an incoming CSID cannot be changed. Did the person in that post solve the problem? Did I understand the Caller ID solution properly in that a fax telephone number would be entered into the CSID thereby avoiding commas? Do you have any other work around ideas? Otherwise I guess it’s back to a non-network arrangement.

The feature of Winfax I find very useful is the ability to link the phonebook to a table in an SQL database. Snappy Fax does not have this feature. Are you aware of any other networkable fax programs that do?

Thank you for your help.

[JohnD]

I’m not sure what the resolution was, if any, to that issue. I’ll look into it to see if there is some workaround.

Have you tried the “Fix Number Entry” fix in the WinFax Tools? Try this on a client machine, and also the host, see if that makes any difference.

As for SQL phonebook linking, no I am not aware of any other fax software that has this feature.

[jfreeman]

I tried the fix entry on the winfax tools and this did not change anything. I’m going to try and use the program knowing CSIDs with a comma may crash the program. Thank you for your help. Please let me know if there is a work around.

[JohnD]

@jfreeman wrote:

I tried the fix entry on the winfax tools and this did not change anything. I’m going to try and use the program knowing CSIDs with a comma may crash the program. Thank you for your help. Please let me know if there is a work around.

It doesn’t look promising, but if I can find anything I will let you know. If it can be fixed, it will be added to WinFax Tools.

[JohnD]

Ok, after some further investigation, i’ve found the problem exists in the WFXIFWPP.DLL file.

This only occurs (that I am aware of) in the Receive Dialog box that lists the faxes when you connect a client to a Host.
The problem occurs when the list box in this receive dialog box is populated. The information is received from the Host machine, and then it is filled in this list box, where you can select individual faxes to download on the client.
There are only 5 pieces of data that is populated in the list box, they are:

Time, Date, Fax Type (if it is a voice message or fax) , pages , and the CSID.

The problem is these 5 items are seperated by commas when the information is read by WinFax. Time, Data, Fax Type and Pages never will include a comma in the data, but the Remote CSID could possibly have a comma, so when CSID string includes one or more commas, the data becomes split into 6 or more fields, when WinFax is expecting only 5.

Did the data appear correctly under the headings for these bad faxes on the client Receive dialog box? In my tests, the data was shifted and did not match the headings.

[jfreeman]

I believe it is just as you have explained. I have been using Winfax on stand alone computers for several years with no problems and it was by chance I stumbled upon this issue when I updated to a network arrangement. By chance, the CSID from a test computer contained a business name with a comma and not a telephone number so the first time I tried it I received an error. The error signature contains AppName: wfxctl32.exe ModVer: 10.4.2005.125 AppVer: 0.0.0.0 Offset: 0001c14c ModName: wfxifwpp.dll

If I send a fax from a client containing a CSID with a comma, it receives fine at the host but once I exit the program from a client on the network and then reconnect, I receive the above error without the Receive folder appearing. I have to exit the program again at the client, reconnect and then I can see the Receive folder but as you noticed, the fields contain incorrect data with a shift of information. The Time field has a phone number from a prior received fax, the Type field has a time in it, the Date field has digits in it but not in date format, The Pages field has a date in it and the CSID field has pages in it. If I then click on Show All Messages, the error repeats itself. Once I delete the fax with CSID containing a comma on the host the problem goes away.

Is there any way you can fix the wfxifwpp.dll file or is this something only Symantec could have done? Is there a work around? The only work around I see right now is if the program crashes from a client then there must be a fax in the host receive log with a comma in it which must be read and either archived or deleted in order to resume normal program function.

Thanks again for your help.

[JohnD]

@jfreeman wrote:

Is there any way you can fix the wfxifwpp.dll file or is this something only Symantec could have done? Is there a work around? The only work around I see right now is if the program crashes from a client then there must be a fax in the host receive log with a comma in it which must be read and either archived or deleted in order to resume normal program function.

I did my tests with TalkWorks PRO 3.0, so this problem existed since at least 1999 and was carried over to WinFax PRO 10. In 2006, the Wfxifwpp.dll file was also updated with the WinFax PRO 10.04 update, but I don’t believe this issue was fixed (or even acknowledged by Symantec). Symantec could have fixed this, and probably the easiest solution would be to strip out comma’s from the Remote CSID before it is saved to the receive log (in the component where faxes are received, not the wfxifwpp.dll file).

The only workaround I can see is to manually check the Host’s receive log, and move any received faxes with a Remote CSID that include a comma to another folder.

FaxTalk is releasing a new version very soon which will include Fax Sharing, which works similiar to WinFax’s sharing. We’re currently evaluating their software, and we’ve found it is the only software that is very similar to WinFax with a reasonable price for small business. It also has the ability to import WinFax logs and phonebooks (WinFax must be installed on the same PC to do this). It does lack the extensive phonebook links of WinFax. The software is available as a trial download here: http://store.getfaxing.com

[jfreeman]

For now I’ll create a separate folder for the problem faxes as I suspect this will not occur very often.

I appreciate your help and I will check out your link to FaxTalk.

[JohnD]

I did some more digging, and Symantec was aware of this problem at least as of June 2001. I don’t think the actual cause of the error was properly investigated, so it never was fixed.

http://service1.symantec.com/SUPPORT/faxprod.nsf/docid/2001062114295604

and another here:

http://service1.symantec.com/SUPPORT/faxprod.nsf/docid/2000081810090604

We know now that the actual solution is to remove any entries in the receive log with bad Remote CSIDs (with commas)

[Author]

Posts