Troubleshooting
Common Information and Error Codes, RDP Debug Mode
Common Informational and Error Codes
There are inevitably going to be situations where you receive a code for either informational or error conditions. Below is a table that covers the most common codes and messages you may receive.
These error messages will show up either in pop-up messages during your session, or in an event log that is being analyzed post-session.
| Error / Exit Code | Type | Description | Frame Component | FRP Version |
|---|---|---|---|---|
| 4000 | Info | User initiated close to the session. This occurs mostly through choosing "Close Session" in the gear menu. | Server | FRP 7/8 |
| 4001 | Error | An unknown critical error occurred on the server. | Server | FRP 7/8 |
| 4002 | Error | Connection rejected due to Unmatched Server and Terminal session configuration detected. Either the wrong data was sent from the Terminal, or the data was corrupted. | Server | FRP 7/8 |
| 4003 | Error | Server Send Buffer Overflow. | Server | FRP 7/8 |
| 4004 | Error | An unknown critical error occurred on the server. | Server | FRP 7/8 |
| 4005 | Error | Similar to 4004. An unknown critical error occurred on the server. | Server | FRP 7/8 |
| 4006 | Info | The end user is already in another session. This could be due to two tabs open on the same machine, or two machines sharing the same token owner (Identified email address). | Server | FRP 7/8 |
| 4008 | Info | Max session timeout reached. This setting is set in the "Session Settings" section of an account or in the "Session Settings" section of a launchpad's settings (Override the account settings). | Server | FRP 7/8 |
| 4009 | Info | IDLE Connection timeout. This occurs when a disconnected session has not been reconnected within the allotted time specified in "Settings Settings" for an account or launchpad. | Server | FRP 7/8 |
| 4011 | Error | Error occurred in the video stream of an active session. Please attempt to reconnect and contact Frame support if you continue to have problems. | Server | FRP 7/8 |
| 4015 | Info | The end user or a script shut down the VM (Windows and Linux). | Server | FRP 7/8 |
| 4018 | Info | The end user or a script logged off from the VM (Windows and Linux). | Server | FRP 7/8 |
| 4019 | Info | The VM from which the session is running has been externally shutdown, or the session was closed remotely. This can occur from an Admin API, manual session close in the account dashboard, or through an expected Frame automation. | Server | FRP 7/8 |
| 4022 | Error | On a domain-joined instance, the end user's profile failed to mount. | Server | FRP 7/8 |
| 4023 | Error | The server closed the connection due to too many registered receive timeouts. | Server | FRP 7/8 |
| 4024 | Error | The server registered an error in the receive thread. |
Server | FRP 7/8 |
| 4025 | Error | The server registered an error in the send thread. |
Server | FRP 7/8 |
| 4026 | Error | An unknown error occured in the FRP8 connection. | Server | FRP 8 |
| 4027 | Error | The virtual display is not in the correct state during session start (Virtual display failed, or is not ready) | Server | FRP 7/8 |
| 4028 | Error | The session connection to the secondary monitor/display closed when not responding to a change request. | Server | FRP 7/8 |
| 4029 | Error | The session connection closed unexpectedly. | Server | FRP 7/8 |
| 4101 | Error | Terminal failed to connect to the server within the window of the allotted connection time (Connection Timeout). | Terminal | FRP 7/8 |
| 4102 | Error | The connection between terminal and server appears to have been severed by the network connection. | Terminal | FRP 7/8 |
| 4103 | Info | Terminal is attempting to reconnect after a disconnect | Terminal | FRP 7/8 |
| 4106 | Error | Terminal failed to reconnect to a server after a disconnect | Terminal | FRP 7/8 |
| 4107 | Error | Signaling Peer Timeout. The signaling server did not get the server peer ID within the allotted time. | Terminal | FRP 8 |
| 4108 | Error | The WebRTC ICE connection has been disconnected. | Terminal | FRP 8 |
| 5006 | Error | The WebRTC ICE connection failed due to network issues or a misconfiguration. | Variable | FRP 8 |
| 5007 | Error | The WebRTC negotiation process timed out. | Variable | FRP 8 |
| 5008 | Error | The WebRTC peer connection failed to connect. | Variable | FRP 8 |
| 5009 | Error | The STUN server could not be reached within the allotted time. | Variable | FRP 8 |
| 5010 | Error | The TURN server could not be reached within the allotted time. | Variable | FRP 8 |
| 5019 | Error | FRP8 could not connect to either the STUN or TURN server. | Variable | FRP 8 |
RDP Debug Mode
A Frame administrator may encounter the need to access a persistent VM (Sandbox, Utility Server, or persistent desktop) using Microsoft Remote Desktop Protocol (RDP) for a number of scenarios.
- Unable to access the Sandbox VM using Frame Remoting Protocol (FRP)
- Perform a task that requires RDP
- Troubleshoot a persistent desktop VM
If RDP sessions are necessary, Frame provides administrators with the RDP Debug Mode feature to enable a non-persistent or persistent VM to be powered up and to allow an RDP session to be established.
While a VM is in RDP Debug mode, a user will not be able to access the VM using FRP.
Using Debug Mode
- From the Frame Account Dashboard, browse to the VMs page.
- Find the machine you wish to debug and click the kebab menu on the far right, then choose Enable RDP Debug.
The machine must be powered down prior to enabling RDP Debug. If the machine is not powered down first, the administrator will see a notice "The server must be in stopped state".
- In the RDP Debug mode window, enter the IP address of the machine you want RDP access from. The administrator’s Public IP address will automatically populate. Enter additional IP addresses if multiple administrators require access. Click Enable to enable RDP Debug Mode.
Tip
The Whitelisting workflow only applies to Public Cloud with Frame Managed Public Networking. If using an SGA, you will RDP into the Private IP address of the machine and you will not have direct RDP access to the machine over the Internet. You must have access to RDP to the Private IP address. One way to accomplish this is to launch a Frame session in the same Account and then RDP into the machine using the information provided once RDP debug mode is enabled within the Frame session.
- When the Enable button is clicked, Frame Control Plane will kick off the orchestration to boot the VM in RDP Debug mode.
- When the VM is powered on and ready to accept an RDP session request, the Enable RDP Debug mode window will display RDP information required to accerss the VM using RDP. Each of the fields has a copy icon next to the field value so you can easily copy the information to your RDP client.
The fields are:
- Server IP: IP address of the VM
- Server public hostname: Fully qualified domain name of the VM
- User: Local Windows user that you can use to RDP into the VM. If this Frame account was created with a BYO image, you can use the user account that you created when preparing the template image.
- Password: Password for the local Windows user. This password is valid until the VM is powered off or rebooted. Once the VM is powered on again, the password will no longer be valid.
- Using your RDP client, connect to the VM using the VM's IP address. Depending on your deployment model, the VM's IP address may be a private or public IP address. You will be asked to confirm the VM's public key certificate before reaching the Windows login screen.
The RDP Debug mode lasts until the VM is powered down or rebooted. If you log out of an RDP debug session, but don't power down or reboot the VM, you can start a new RDP session using the same RDP information.