One of our customers is reporting a very strange behavior pattern. They launch our app - things work fine for an hour or so - then certain pages start to fail. The error that consistently comes up is "Invalid path or file name" but it is triggered by different commands depending on the method.

 cClassLib = [awBusinessObject.prg]
 loProduct = NEWOBJECT(cClassName,cClassLib,Server.oSys.cExe)
      
SET PROCEDURE TO wwDotnetBridge ADDITIVE

SET PROCEDURE TO wwAPI ADDITIVE

In each case it is attempting to access a PRG based class library - but all of the PRGs in question should be compiled into the exe - how can they not be located?

Not to mention that all of these methods work initially - as noted the problems only show up after an hour or so of activity. If we reset IIS, everything will start working again for a while. I would also note that we have the identical exe running on other customer sites with no evidence of this problem.

The last thing we did was switch them from Com to File mode - at last report, they had been running for several hours without seeing any failures. So was the problem somehow tied to Com operation?

If anyone can shed any light on this, I'd appreciate your suggestions.

--sg

That sounds like potential COM Server corruption. You might want to check the Web Connection server logs and see what errors are being thrown prior to the failures or as they happen.

Especially if running ISAPI many COM failures (ie. servers getting force released frequently) can end up causing corrupted instantiations of objects. Less of a problem with .NET module, but even there can be a problem as that is a COM system issue. Bottom line - make sure servers are not getting force released all the time.

+++ Rick ---

Following up on this in case anyone is interested... [And if you're really interested, note correction below...]

They were running under ISAPI so one of the first things we did was put them on .NET but unfortunately that did not resolve the issue.

We checked various error logs but were unable to come up with anything conclusive. *Finally just spun up a new server instance, installed our app from scratch and loaded the data from backup. *

OK, they were considering that option but it turns out they first tried just switching to File Mode. That appears to have solved the problem as things have been running smoothly ever since. Never did figure out what the COM issue was, but given how robust File Mode is under .NET, they might as well just stick with it.

--sg

I'm investigating this issue with Stein. I was able to track some of the webconnect error messages to this entry: __WebPageList.Filename Not sure how that entry is fine for a while and then goes caput (Invalid Path or File Name).

Also of note, this is only happening to customers and test instances where they are running multiple script maps with multiple database locations. From what I can tell, the above cursor entry is for the executable running, so I'm not sure why this is the factor that is corrupting things.

Any ideas?

Thanks, Matthew

This cursor is from the Web Control Framework that keeps track of compiled program files. It looks to me that this cursor is getting corrupted, but not sure how that happens.

If the cursor is closed accidentally it'll just get recreated so that can't be the problem. And there's only one place where this table gets written to in webPageParser.prg.

Can you tell what the issue is actually? Is the table corrupt? Is it pointing at a file that is no longer there? Is the FXP or PRG it's trying to run corrupt (if compiled)?

You do have to be careful with updating files into a live running application - if you update these Web Control files, you need to make sure the app gets restarted so that cursor gets recreated with new info and the cached FXPs are recognized by all the executing instances.

+++ Rick ---

This cursor is from the Web Control Framework that keeps track of compiled program files.

That might explain why we're getting these invalid path errors on SET PROCEDURE calls that point to PRGs that should be compiled into the main exe.

FWIW, this is no longer limited to a single customer site - we've seen it happen in mulitple cases. After upgrading a client to our latest version, if they're running in COM, it will work initially but they'll start getting the errors at some point. The solution in each case has been to switch the to File Mode.

We have a well-established upgrade procedure that involves stopping IIS and unloading all servers so I do not think that is the issue. Evidently the problem is triggered by something we did to our code prior to the last release, but we have no clue what that might be. We definitely did not mess around with anything at the webPageParser level. We thought it might be just a glitch in the compiled exe, but we've since rebuilt and recompiled the app after upgrading to WC 7.40. The issue persists with the new exe.

If the PRGs are compiled in then there shouldn't be any files on disk to match them at the deployed site - they'll just be found from the exe.

However I would make sure that the files are not in the folder when they are also compiled in - my guess they are and the difference between what's compiled and possible external files might be the problem that you see.

Said another way: You don't what to have both compiled and loose PRG/FXP files. One or the other.

+++ Rick ---

Update: I was able to set up a server with our application and duplicate what some of our users were reporting on there. This was then the baseline to work from.

Not know what else to do, I put all SET PROCEDURE calls in an IF to be sure they actually needed to be called. I had a typo in one of my IFs and wouldn't you know it, that was the one that failed within a day or so. After fixing that one, I've not had any issues since. The IF statement is of the form:

IF ATC([wwAPI],SET("Procedure"))=0

I'm not sure if the extraneous SET PROCEDURE calls were what were corrupting things or getting lost in everything else, but I'm at least ready to put something into production for these people to try. Hopefully, they can see the same results I am getting.

Anyway, if you don't hear from me, assume the above as the fix.

Thanks, Matthew

If you had a typo in there that would mean that library wouldn't get loaded, so that would explain the failure.

FWIW, in theory there should be no problem with doing a SET PROCEDURE with an already loaded library - FoxPro should be smart enough to not try to reload it, and if it loaded it from the EXE the first time, it should load it from there again. The main issue that could come in is if it's a 'dynamically' loaded reference that hardcodes the path (such in the case of a WCF Page).

To avoid any loading overhead is why I recommend loading all dependencies on startup, using a loader of some sort that loads everything. Also, ideally PRG files declare their dependencies at the top with their own SET PROCEDURE TO and SET CLASSLIB TO dependencies so you each class/component can load all its dependencies with DO MyPrgFile.prg

+++ Rick ---

Found a new instance late last week and I'm not sure what to do about it other than to not use this function. This is in wwUtils in the GetUniqueId function:

DECLARE INTEGER CoCreateGuid ;
	  IN Ole32.dll ;
	  STRING @lcGUIDStruc

This is throwing the same Invalid Path or Filename error. I did search the server and there are multiple copies of it in various Windows folders. An IISRESET does allow it to run fine for a while (sometimes just a short while). I don't write code like this, so that is part of my hang-up here. It would look like only West Wind classes (wwRequest, wwSession, and wwUserSecurity) are the only things using it in my code. So, rather than subclassing all of that, I was hoping someone had a quick fix for me.

Thanks, Matthew

Not sure how that can happen. Ole32.dll is a System DLL that lives in the Windows folder, so that should always be available on any Windows machine with any level of permissions.

Could it be that your error is not pointing at the right line of code?

I did make a change and removed the wwAPI declaration for function registration and moved it to the two places in the library where they are used, so now they only are referecned when actually used.

However, for Web Connection I think you'll always end up using it anyway as GetUniqueId() uses this which is used for Session IDs.

+++ Rick ---

Yes, I am sure of the line of code.

New one. Looks like CREATEOBJECT is getting the same error. Here is one example from wwPageResponse.ExpandPage:

oParser = CREATEOBJECT("WebPageParser")

But, I haven't fixed the GetUniqueId issue as of yet, so maybe it's fallout from that crashing out. Anyway, I'm losing my mind as I thought this issue was dead and buried with my fix from May!

Thanks, Matthew

What I'm saying is that error messages coming out of VFP are not always accurate, they can be off by a few lines or a call in the call stack.

I just don't see how a system DLL declaration - especially if it's already been loaded and internally won't reload most likely since you say it happens after some time - can fail. The system path is always available unless the entire process has been corrupted and the environment is hosed.

There's a problem but I have a hard time tracking it to that particular line of code.

I understand your point on error lines being off. Especially with try/catch or having out of synch code with the running environment, things get off. However, if I just say the error message is incorrect, I still have no idea where the problem is.

Here is a recent example. I have debugviewer.prg that opens with this code:

#INCLUDE WCONNECT.H

*** Small Stub Code to execute the generated page
PRIVATE __WEBPAGE
__WEBPAGE = CREATEOBJECT("DebugViewer_Page_WCSX")
__WEBPAGE.Run()
RELEASE __WEBPAGE
RETURN

*****************************************************************
DEFINE CLASS DebugViewer_Page as WWC_WEBPAGE OF WWC_WEBPAGE_FILE

The error is: Message: Invalid path or file name. Program: debugviewer_page Line No: 5 Line 5 is the CREATEOBJECT call. It is trying to create the object in the same file. So how can there be an invalid path or file name? This is baffling me. Oh, and it was about an hour after switching to COM mode. It'll run just fine in FILE mode, just not in COM. When this is failing, it is around the hour mark. An iisreset does fix things for another hour or so. To me, switching to FILE mode is a workaround, not a solution.

Thanks, Matthew

It's not the same class that is referenced in the file. Note the _WCSX at the end.

How are you running the app? Make sure that you precompile your pages either by including them in the EXE or by running the server in pre-compiled mode page mode. If pages are being recompiled at runtime for whatever reason you can run into race conditions where one instance ends up locking an FXP file or creating an invalid FXP file that then causes the other instances to not find the file.

The other thing could be that there's some change in your pathing that then fails to find the compiled FXP files.

+++ Rick ---

Precompiled. PageParseMode=3.

I think the path is defined in the awp as such (at least in the previous example):

GeneratedSourceFile="Aceweb\DebugViewer_Page.prg"

Is there a better way to define paths?

Thanks, Matthew

If you're precompiled then the FXP should be in memory after first load and not try to reload.

Is it always the same page/class that fails?

The only other thing I can think of is that the entire procedure file stack gets blown by an errant SET PROCEDURE TO in which case everything ends up reloading.

+++ Rick ---