It's important to observe and understand the type of errors during installation. Certain errors are informative whereas other errors may require you to restore from your backup.

1. Error "Maximum request length exceeded" during upload.
   
   See how to avoid timeout for more info.
    
2. Error "Could not load file or assembly 'IKVM... The located assembly's manifest definition does not match the assembly reference."
   
   If this error occurs only when the page is first loaded immediately after an installation, it is usually caused by IIS reloading the libraries and there's a temporary mismatch in the cache and is usually safe to ignore. It will clear on its own by reloading the page.
   
   If, however, the error persists or happens everytime the Web site is restarted, you should investigate if you have conflicting DLLs (in particular, you should verify if you have the older bin\IKVM.GNU.Classpath.dll file and see if it can be removed safely. This DLL may have been included from other modules and is considered deprecated since it has been replaced with IKVM.OpenJDK.*.dll, IKVM.Runtime.dll by the IKVM community and may cause conflicts.)
    
3. Database installation error or installation failed error message.
   
   If you have database errors during installation, you should take note of the error and attempt to restore from your backup. Contact technical support for assistance.
    
4. Error message “Attempted to access an unloaded AppDomain”
   
   Simply restart your IIS application pool to notify IIS that new DLLs have changed.
    
5. Error on page "DotNetNuke.Services.Exceptions.ModuleLoadException: Index was out of range...".
   
   This is usually caused by the fact you had deleted or not placed the required module controls somewhere on a page. The required module controls must exists on a page and it could be a hidden page if you don't want it to appear on the menu. See Adding module controls for more info.
    
6. Error on page "Cannot find or load template".
   
   Make sure your configuration, products, catalogs are referencing a display template that exists. Older base display templates may be deleted with new versions of the software. If you're using custom display templates, you also want to check for syntax error and ensure your base display template still exists. See Display Templates for more info.
    
7. Network error accessing REST API resources with 405 Method Not Allowed or 500 Internal Server Error returned.
   
   Your IIS has an older configuration that is disallowing certain common REST API operations from working. For example, you might notice this error when you try to perform a delete or remove operation such as deleting a product item from the shopping cart. To remedy this problem, simply adjust the settings in your IIS Web site:
   
   i. Under the Handler Mappings settings, make sure to edit the settings of every mapping that begins with ExtensionlessUrl* name. Under the Mapping tab, the Invoke handler only if request is mapped to should be unchecked. The Verbs tab should allow DELETE, GET, HEAD, POST, DEBUG, PUT verbs. Under the Access tab should have the Script option selected.
   
   
   
   
   ii. Under the Handler Mappings settings, remove WebDAV if present.
   
   iii. Under the Modules settings, remove WebDAV if present.
   
    
8. Hosted payment gateway redirects back to an empty cart or does not reach confirmation page after successful payment.
   
   Starting in Feb 2020 with gradual rollout, Chrome and most modern browsers will default to a more restrictive cookie policy. Requests made to your page after redirecting back from an external site will no longer honor your existing cookies. Please note this change will affect any Web site that needs to redirect back from an external site or display 3rd party content in an IFRAME that relies on cookies, regardless of the software platform you use.
   
   When you redirect back from a hosted payment gateway such as PayPal, 3D Secure, etc. your existing authentication and cart session are suddenly lost because the cookies are no longer transmitted forward by the browser breaking the checkout process.
   
   You can remedy this problem easily by configuring your web.config file to transmit cookies with an explicit SameSite property. However, this change is only supported by Microsoft if your site targets the .NET framework 4.7.2 or higher and running SSL, which is available when you run DNN 9.4 or higher operating with an SSL certificate. If you're running an older version of DNN, you can try changing the targetFramework="4.7.2" attribute by editing your web.config file.
    

   <system.web>     ...     <compilation ... targetFramework="4.7.2">     ...     <httpRuntime ... targetFramework="4.7.2" >     ... </system.web>

   
   To change the cookie behavior, simply edit your web.config file to modify or add the cookieSameSite="None",  sameSite="None" and requireSSL="true" attributes to the following element tags. If the element tag does not exist in your web.config file, you can simply create the tag and add the attribute.
    

   <system.web>     ...     <sessionState ... cookieSameSite="None" />     ...     <authentication mode="Forms">         <forms ... cookieSameSite="None" requireSSL="true" />     </authentication>     ...     <httpCookies ... sameSite="None" requireSSL="true" />     ... </system.web>

   
   After making the changes and cleared your browser cookies, you can open your developer tools (F12) to verify the cookies are generated with "None" values for the SameSite property. For example, the "ASP.NET_SessionId" should have the "None" value. If you add a product to cart, the "rvdsfcart|0" cookie should also have the "None" value.
   
   
   
   If it still doesn't work, this could mean your Windows server does not have all the latest updates. Try installing the Windows Update KB4533002 on your server and restart the server. Remember to clear your browser cookies to see the changes.
   
   Please note the SameSite property has no effect on older Apple browsers running IOS12 and older due to a known Apple bug. Since this bug should not happen on newer IOS versions, Apple has decided not to pursue a fix for it.
    
9. Javascript error caused by reading an undefined property from a returned API call.
   
   You can confirm this type of error by inspecting the Network section in your browser developer tool. Look for a REST API return call with a non-success response code (e.g. 400, 500 error response codes). In the response body, if you see HTML data instead of JSON data indicates your error messages are being overridden by your IIS configuration.
   
   To remedy the problem, make sure your IIS web.config does not specify a custom error message using the httpErrors section. Specifying a custom error message will prevent any REST API from correctly returning the necessary JSON data that is expected by the Javascript code on the page.
   
   If you still experience the problem, you want to make sure your web.config is allowing extension-less requests to be handled correctly. The following settings should normally be present in your web.config file.
    

   <remove name="ExtensionlessUrl-Integrated-4.0" /> <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />