I've updated the bug report item's status to Declined, as this is not an actual bug report but rather a support ticket related to an obsolete product.

Hi Craig,

Thanks for the additional details! The difference you found (lower envs using a physical D:\ path vs Demo/Prod using a UNC share like \\fs01\...) is very likely the root cause.

When RadChart runs in IIS, image loading is done under the Application Pool identity, not under your interactive Windows user. So even if the share works when you browse it manually, it can still fail for the worker process due to missing permissions or how UNC resources are accessed by service accounts.

To move this forward, please check the following:

1. Confirm the Application Pool identity
   In IIS - Application Pools - (your pool) - Advanced Settings - Identity.
   Ensure this exact account has Read permissions on the share (both Share Permissions and NTFS). In some environments, granting permissions to both the App Pool identity and the web server machine account may be needed.
2. Recommended: Configure an IIS Virtual Directory to the share
   This avoids relying on file system paths in the chart configuration and lets IIS handle access to the share.
   Once configured, point RadChart to a URL path instead:

   item.Appearance.FillStyle.FillSettings.BackgroundImage = "/SharedImages/bkgSavingsXLarge.png";

3. Quick verification
   Try opening the image directly in a browser through that virtual directory URL.
   If it prompts for credentials or returns 403/404, that confirms the issue is IIS/share access rather than RadChart itself.

Mapped drives plus registry workarounds (EnableLinkedConnections) can sometimes bypass this, but it is typically not recommended for production IIS applications.

Regards,
Rumen
Progress Telerik

Hi Craig,

Thanks for the RadChart snippet - that helps. Since RadChart can resolve background images differently depending on how the chart is rendered (on-page vs export/print), there are a couple of ways to set BackgroundImage. Please try the options below to see which one matches your scenario.

Option 1 - Client-accessible URL (on-page rendering)

If the chart is rendered directly on the page and the browser is responsible for loading the image, use a resolved URL (this also handles deployments under a virtual directory):

item.Appearance.FillStyle.FillSettings.BackgroundImage = ResolveClientUrl("~/images/bkgSavingsXLarge.png");

Option 2 - Physical file path (export / print scenarios)

If the issue occurs only in printed or exported output, RadChart may need a physical file path so it can load the image server-side:

item.Appearance.FillStyle.FillSettings.BackgroundImage = Server.MapPath("~/images/bkgSavingsXLarge.png");

Additional notes

• Avoid using backslashes (for example ~\Images\...) - use forward slashes and resolve the path explicitly.
• Hard-coded absolute paths (for example C:\...) are not recommended for production deployments.
• If the image is expected to load via URL, please verify it is accessible directly in the browser and not blocked by IIS or web.config rules:
  https://<your-domain>/<your-app-if-any>/images/bkgSavingsXLarge.png

Please try both options and let us know:

• whether the background image is missing in the on-page chart, exported/printed output, or both
• which of the two approaches works in your Production environment

I understand your point, RadChart can be a good fit for scenarios where the end goal is a static PNG image for printed reports, which is why the above steps focus on making it work reliably in your current setup. That said, for completeness, RadHtmlChart also supports server-side export to PNG and PDF, which can cover similar reporting scenarios while using a newer rendering pipeline:

• Exporting RadHtmlChart to PNG and PDF
• Server-side export to PDF

Regards,
Rumen
Progress Telerik

Hi Craig,

Thank you for reaching out. Based on your screenshots, it appears you're using RadHtmlChart (not the deprecated RadChart). Since the background images work in your local, Dev, and QA environments but not in Production, this suggests an environment-specific configuration or resource access issue.

Troubleshooting Steps:

1. Browser Developer Tools - Network Tab
   • Open DevTools (F12) and check the Network tab when the chart loads
   • Look for failed requests (404, 403 errors) for your down-arrow image files
   • Check if the image paths are being blocked or returning errors
2. Browser Console - JavaScript Errors
   • Check the Console tab in DevTools for any JavaScript errors
   • RadHtmlChart renders client-side, so JS errors could prevent proper rendering
3. Image Path Configuration
   • Use application-relative paths: ~/Images/down-arrow.png
   • Avoid absolute paths or hard-coded server names that may differ between environments
   • Verify the path resolves correctly in production
4. File Existence and Accessibility
   • Confirm the down-arrow.png files are deployed to the Demo/Production servers
   • Verify they're in the correct folder location
   • Check the files aren't corrupted or blocked
5. IIS Permissions
   • Ensure the IIS application pool identity has read permissions for the image folder and files
   • Permission issues often differ between Dev and Production environments
6. Case Sensitivity
   • "down-arrow.png" vs "Down-Arrow.png" matters on case-sensitive systems
7. Web.config Review
   • Check for request filtering rules that might block image requests
   • Verify MIME types are configured for .png files
   • Look for any custom HTTP handlers that might interfere
8. Direct Image Access Test
   • Try accessing the image directly in your browser: https://yourdomain.com/Images/down-arrow.png
   • If this fails, the issue is with file deployment or server configuration, not the chart

Could you please provide a code example showing how you're setting the BackgroundImage on the series items along with a screenshot of your DevTools Console and Network tab? This will help us provide more specific guidance if the above troubleshooting steps don't resolve the issue.

Regards,
Rumen
Progress Telerik