I am monitoring our Microsoft Remote Desktop Gateway website using an HTTP sensor. Whenever the sensor trigger, the server logs a warning event, ID 1309. The sensor is using GET, and is not inheriting SNI. Not sure if my sensor needs adjusting. Event log entry follows...any ideas?

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          2/6/2019 2:34:33 PM
Event ID:      1309
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      <hostname redacted>
Description:
Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 2/6/2019 2:34:33 PM 
Event time (UTC): 2/6/2019 10:34:33 PM 
Event ID: 47a37f7c251f4a20b35e6e079ea8d8e5 
Event sequence: 18775 
Event occurrence: 2575 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT/RDWeb/Pages-1-131918875365100057 
    Trust level: Full 
    Application Virtual Path: /RDWeb/Pages 
    Application Path: C:\Windows\Web\RDWeb\Pages\ 
    Machine name: ********
 
Process information: 
    Process ID: 2044 
    Process name: w3wp.exe 
    Account name: IIS APPPOOL\RDWebAccess 
 
Exception information: 
    Exception type: NullReferenceException 
    Exception message: Object reference not set to an instance of an object.
   at Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSFormAuthTicketInfo..ctor(HttpContext objHttpContext)
   at ASP.en_us_default_aspx.<GetAppsAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.UI.PageAsyncTaskManager.<ExecuteTasksAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.UI.Page.<ProcessRequestAsync>d__554.MoveNext()

 
 
Request information: 
    Request URL: https://<hostname redacted>:443/RDWeb/Pages/en-US/Default.aspx 
    Request path: /RDWeb/Pages/en-US/Default.aspx 
    User host address: <IP address of PRTG monitor>
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: IIS APPPOOL\RDWebAccess 
 
Thread information: 
    Thread ID: 65 
    Thread account name: IIS APPPOOL\RDWebAccess 
    Is impersonating: False 
    Stack trace:    at Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSFormAuthTicketInfo..ctor(HttpContext objHttpContext)
   at ASP.en_us_default_aspx.<GetAppsAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.UI.PageAsyncTaskManager.<ExecuteTasksAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.UI.Page.<ProcessRequestAsync>d__554.MoveNext()

Article Comments

Are you just calling the URL of the page (i.e. the login form) or do you provide it with any POST data for authentication purposes?


PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team


Feb, 2019 - Permalink

The former, since I am not familiar with what data would be sent in a POST. Is that likely causing the warning? If so, I can research what to use in a POST request.


Feb, 2019 - Permalink

I figured it out! It wasn't the sensor settings at all. The system time on the webserver was off by about a minute. Once I changed the time source so that NTP worked properly, these warnings went away.


Feb, 2019 - Permalink

Hi Jeff,

Thanks for the update, glad it's up and running now.


PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team


Feb, 2019 - Permalink