Developers are more and more creating applications on containers, and guess what? It’s still up to us – ITPros – to troubleshoot anything that happens in production. Containers are not VMs, so where to even start, you might ask.  We’ll show you the path to troubleshoot Windows containers, so you can still deliver on this – In fact, we will do this progressively. Today’s blog post is the first one in a series of blog posts on which we’ll build on the knowledge of the previous to help you gain an understanding of how to troubleshoot applications running on Windows Containers.

Developers are more and more creating applications on containers, and guess what? It’s still up to us – ITPros – to troubleshoot anything that happens in production. Containers are not VMs, so where to even start, you might ask.  We’ll show you the path to troubleshoot Windows containers, so you can still deliver on this – In fact, we will do this progressively. Today’s blog post is the first one in a series of blog posts on which we’ll build on the knowledge of the previous to help you gain an understanding of how to troubleshoot applications running on Windows Containers.

What is the difference between Windows VMs and Windows Containers for troubleshooting purposes?

Before we dive into the troubleshooting portion, it’s important to compare the method used to troubleshoot an application. As an Ops person, if a system is faulty and you need to troubleshoot it, most likely your first action is to “RDP” or remote connect into that server. Well, that’s just not an option with containers. In fact, on services like Azure Kubernetes Service (AKS) you don’t even have access to the host running your container itself. So, how do we manage and troubleshoot Windows Containers?

As I mentioned, in this series we will explore multiple options to troubleshoot applications running on Windows Containers. In this first one, we will explore the most basic one – running a container interactively. For the purpose of this blog, think of how an app on a container sees the underlying OS as you would think of a Virtual Machine: For the container and the app itself, the underlying host and hardware were abstracted, but the application is still running on an OS. That OS is still a Windows OS and while the Graphical User Interface (GUI) is not present, the other components of the OS are. In fact, a Windows Container instance is not much different from a Server Core instance for troubleshooting purposes. Sure, you can RDP into a Server Core server or use other tools to aggregate logs and info from that faulty Server Core server, but the point of this blog post is to teach you the basics. Containers can also leverage other troubleshooting tools, but understanding the underlying OS and its components will help you in the long run. By knowing where to look into, you understand the concept of troubleshooting the system and then fancy tools become just a way to accelerate the troubleshooting process, but you understand the overall concept behind it.

So, how do we connect interactively to a Windows Container?

As mentioned, Windows Containers don’t have a GUI or a Desktop. The way we connect to a Windows Container instance is via PowerShell (remember the Server Core analogy?). In fact, we use the Docker tooling on a container host to open an interactive PowerShell session to a running container. Note: You could also open a Command Prompt (CMD) session to a Windows Container, but PowerShell ends up being more useful)

In this blog post I touched in more details how to open an interactive session to Windows Containers. The simplest way to do it is by running the following:

docker run --entrypoint powershell -it --name testcontainer mcr.microsoft.com/windows/servercore:ltsc2022

The command above creates a new container and opens an interactive session to it. The trick there is the “-it” for interactive (the opposite is to use “-d” for detached). In addition, we used the --entrypoint option to indicate the session should be opened using PowerShell (The other option here would be “CMD”).

With the session opened, you can “browse” around that Windows Server instance inside the container as you would on a Server Core.

The basics – Event Viewer

Where else to start, right? But, have you ever used Event Viewer via PowerShell? It’s actually pretty cool. The way to start here is by looking at the command we’ll be using to look at the logs:

Get-WinEvent

Alright, the usage of the command above “as is” is not very useful, right? It pretty much brings the latest logs on your system. A whole bunch of them. So, let’s start filtering it. First, let’s look at what event logs are available to us:

Get-WinEvent -ListLog *

The command above returns all event logs available for us. The familiar ones are the usual System, Application, Security, etc. We can start looking at them more specifically:

Get-WinEvent -LogName Application

The command above returns the latest logs under Application. However, still the output is not ideal for us to troubleshoot. Unfortunately, the Get-WinEvent command does not provide additional parameters for further filtering. Instead, we need to use regular PowerShell language to further filter the results:

Get-WinEvent -LogName Application | Where-Object { $_.LevelDisplayName -eq \"Error\"}

The command above filters the results on the Application log to show only the Error ones. You can also look for Warning or Information. The same way, you can also change the “LevelDisplayName” for specific error IDs that you’re looking for.

Finally, the information inside each item is probably truncated on the PowerShell session, so you can make the visualization of the events better, by simply adding the format-list option at the end of the command:

Get-WinEvent -LogName Application | Where-Object { $_.LevelDisplayName -eq \"Error\"} | fl

The above command formats the results in a nicer way so you can actually see the whole error message on each item.

There are many other ways to further filter the Event Log. You can find more information on how to do that in the documentation page.

Conclusion

This blog post covers the most basic way to troubleshoot Windows Containers – by looking at the Event log via PowerShell. In no way is this scalable or productive, but it is the foundation to understanding how to retrieve logs from a Windows container interactively. There are many tools out there that make the process of troubleshooting easier and in the next blog post we will explore one of them: The Log Monitor tool.

I hope this content was useful – if not for Windows Containers, you can still leverage this when troubleshooting a Server Core VM. Let me know what you think in the comments below.

Developers are more and more creating applications on containers, and guess what? It’s still up to us – ITPros – to troubleshoot anything that happens in production. Containers are not VMs, so where to even start, you might ask.  We’ll show you the path to troubleshoot Windows containers, so you can still deliver on this – In fact, we will do this progressively. Today’s blog post is the first one in a series of blog posts on which we’ll build on the knowledge of the previous to help you gain an understanding of how to troubleshoot applications running on Windows Containers.

What is the difference between Windows VMs and Windows Containers for troubleshooting purposes?

Before we dive into the troubleshooting portion, it’s important to compare the method used to troubleshoot an application. As an Ops person, if a system is faulty and you need to troubleshoot it, most likely your first action is to “RDP” or remote connect into that server. Well, that’s just not an option with containers. In fact, on services like Azure Kubernetes Service (AKS) you don’t even have access to the host running your container itself. So, how do we manage and troubleshoot Windows Containers?

As I mentioned, in this series we will explore multiple options to troubleshoot applications running on Windows Containers. In this first one, we will explore the most basic one – running a container interactively. For the purpose of this blog, think of how an app on a container sees the underlying OS as you would think of a Virtual Machine: For the container and the app itself, the underlying host and hardware were abstracted, but the application is still running on an OS. That OS is still a Windows OS and while the Graphical User Interface (GUI) is not present, the other components of the OS are. In fact, a Windows Container instance is not much different from a Server Core instance for troubleshooting purposes. Sure, you can RDP into a Server Core server or use other tools to aggregate logs and info from that faulty Server Core server, but the point of this blog post is to teach you the basics. Containers can also leverage other troubleshooting tools, but understanding the underlying OS and its components will help you in the long run. By knowing where to look into, you understand the concept of troubleshooting the system and then fancy tools become just a way to accelerate the troubleshooting process, but you understand the overall concept behind it.

So, how do we connect interactively to a Windows Container?

As mentioned, Windows Containers don’t have a GUI or a Desktop. The way we connect to a Windows Container instance is via PowerShell (remember the Server Core analogy?). In fact, we use the Docker tooling on a container host to open an interactive PowerShell session to a running container. Note: You could also open a Command Prompt (CMD) session to a Windows Container, but PowerShell ends up being more useful)

In this blog post I touched in more details how to open an interactive session to Windows Containers. The simplest way to do it is by running the following:

The command above creates a new container and opens an interactive session to it. The trick there is the “-it” for interactive (the opposite is to use “-d” for detached). In addition, we used the --entrypoint option to indicate the session should be opened using PowerShell (The other option here would be “CMD”).

With the session opened, you can “browse” around that Windows Server instance inside the container as you would on a Server Core.

The basics – Event Viewer

Where else to start, right? But, have you ever used Event Viewer via PowerShell? It’s actually pretty cool. The way to start here is by looking at the command we’ll be using to look at the logs:

Alright, the usage of the command above “as is” is not very useful, right? It pretty much brings the latest logs on your system. A whole bunch of them. So, let’s start filtering it. First, let’s look at what event logs are available to us:

The command above returns all event logs available for us. The familiar ones are the usual System, Application, Security, etc. We can start looking at them more specifically:

The command above returns the latest logs under Application. However, still the output is not ideal for us to troubleshoot. Unfortunately, the Get-WinEvent command does not provide additional parameters for further filtering. Instead, we need to use regular PowerShell language to further filter the results:

The command above filters the results on the Application log to show only the Error ones. You can also look for Warning or Information. The same way, you can also change the “LevelDisplayName” for specific error IDs that you’re looking for.

Finally, the information inside each item is probably truncated on the PowerShell session, so you can make the visualization of the events better, by simply adding the format-list option at the end of the command:

The above command formats the results in a nicer way so you can actually see the whole error message on each item.

There are many other ways to further filter the Event Log. You can find more information on how to do that in the documentation page.

Conclusion

This blog post covers the most basic way to troubleshoot Windows Containers – by looking at the Event log via PowerShell. In no way is this scalable or productive, but it is the foundation to understanding how to retrieve logs from a Windows container interactively. There are many tools out there that make the process of troubleshooting easier and in the next blog post we will explore one of them: The Log Monitor tool.

I hope this content was useful – if not for Windows Containers, you can still leverage this when troubleshooting a Server Core VM. Let me know what you think in the comments below.

Developers are more and more creating applications on containers, and guess what? It’s still up to us – ITPros – to troubleshoot anything that happens in production. Containers are not VMs, so where to even start, you might ask.  We’ll show you the path to troubleshoot Windows containers, so you can still deliver on this – In fact, we will do this progressively. Today’s blog post is the first one in a series of blog posts on which we’ll build on the knowledge of the previous to help you gain an understanding of how to troubleshoot applications running on Windows Containers.