We are NOT currently setting DeleteOldImages to False or True.  Does it have a default?  Perhaps it is set to True by default?

I notice this DeleteOldImages is only on the Gauge and not the Chart.  We never seem to have this image probelm on the Charts.

We index our file names with 0 to 999 and then rollover.  We never delete any files.  We are just overwritting the files. 

We are running on a single web server.  I do not see any errors in the Windows Event logs.  I am also not sure if the ASP.NET worker process is restarting or not.  What would cause this to restart and how can I tell?

Thanks for your help.

DeleteOldImages is set to True by default.  Based on your other answers, I suspect that setting it to False will resolve the problem.

As for the ASP.NET worker process, it sometimes restarts itself if the memory usage gets too high, or crashes unexpectedly.  In XP, this happens under the aspnet_wp.exe process.  In Windows Server, Vista, and Win7, this happens under the W3WP.exe process.  you can monitor the number of ASP.NET application restarts using the system performance monitor (Start > Run > perfmon).

Worker process can also shutdown after an amount of idle time has passed. All of these values are configurable in the IIS settings. In general, don't count on the process remaining alive between requests.

We have this same issue with UltraWebGauge.v10.3 with ASP.NET 4.0. We have a aspx page with many usercontrols. Each contains either a chart, grid, gauge, chart with a grid, or gauge with a grid. We allow for several different types of charts or gauges per usercontrol. The gauges are built with presets. On this aspx page each usercontrol is wrapped with an asp.net updatepanel.

We use the default DeploymentScenario for filesystem. We only supply a path, type, and URL.

We use viewstate on the page and usercontrols. 

One thing to mention is that the image for the gauge that follows the failed gauge is showing in the failed ones place along with where it should.

The charts seem to display consistantly.

As this can happen on back to back postbacks within seconds apart on my local development machine, I would not suspect the cycling of ASP.NET.

While stepping through with a debugger, no exceptions were thrown.

NOTE: We had also attempted without the updatepanel wrapping of each usercontrol with a gauge, but with the same results

jschuebel said:

We have this same issue with UltraWebGauge.v10.3 with ASP.NET 4.0

are you using the latest service release?  a fix was applied in February which might be related to this problem.

It sounds like there's an issue with timing, where the file has been written to the server's file system, but the client request fails to download the image.

What if you set the RefreshInterval property of the gauge?  Would that remedy the problem?

Yes its occuring after removing the session, and i just also saw the case where the gauge image was not created(this is rare case).

How this can happen, is something i need to change in code?

does this still happen when you remove the session ID from the FileName under the DeploymentScenario properties?

this seems like it's a timing issue, and that might be related to ASP.NET having to create the Session for the first time, so maybe that would help.  or, perhaps initializing the session in global.asax, something like this:

void Session_Start(object sender, EventArgs e)

{

Session["nothing"] = new object();

}

And What about below issue

I am getting missing images, these are copied into the filesystem when browse form direct URL then these images displays,

Below is the grid where dymanically createg gauge control displays

Yes, you could safely remove the Session ID from the filename.