You have several possibilities. Each of them with their own Pros and Cons.
Reverse Engineering the Service
The service is just an executable file, so you can load up the binary into a reverse engineering tool of choice (for example, Ghidra, which was developed by our good "friends" over at the NSA) and have a look at what it does.
This has the advantage that you can see exactly what the service does. As an upside, you don't need to worry about any cryptography, since you can see exactly what the service sends as plain text. If you debug it, it may be even simpler.
The downside, of course, is that the service is most likely shipped without debug symbols, and if you're unlucky, in a language that compiled directly to assembler. So debugging may not be a simple task.
Man-in-the-Middle - Naïve Approach
A lot of software has constructs like this:
HttpClient httpClient = new HttpClient();
httpClient.BaseAddress = new Uri("https://example.com/");
var task = httpClient.PostAsXmlAsync<DeviceRequest>("api/GetCurrentVersion", request);
Just standard "How to send a HTTP POST request in C#?" code, right? Notice how the code itself never checks which server certificate is used. What that means is that the runtime will check if the certificate is valid and whether or not it is signed by a Certificate Authority that is trusted by your OS.
So what you can do is to use a proxy server, which serves as an endpoint to the actual server, and then generates a new connection to the service running on your machine. The server will think it is communicating with the service (which is fine, since the service doesn't authenticate itself). The service will think it is communicating with the server, even though it's communicating with the proxy. This is made possible by the fact that the proxy can generate a certificate for the server that is trusted by your local machine.
The exact proxy software used is up to personal preference, as well as the actual protocol being used. TLS merely encapsulates another protocol, which could be HTTP or some other proprietary protocol. HTTPS Proxies are common like sand on a beach, you can use mitmproxy, OWASP ZAP, Burp Suite or any other tool you like or are familiar with. If the protocol is not HTTP, then you need to find another tool. I'm sure Google knows a bunch.
Man-in-the-Middle - Technical Approach
Some companies think they're hot stuff by doing things like mutual authentication and certificate pinning. To quote a colleague of mine:
You're not stopping me, you're just pissing me off.
Mutual authentication means that not only does the client authenticate the server (the default scenario in TLS), but the server also authenticates the client. This is usually done via a client certificate and a private key.
The client certificate, if required, is sent in the
Client Hello packet. You can use Wireshark to see if a client certificate is requested and sent (and dump the certificate form there). Since you mentioned that the service uses TLS 1.2, this is easily possible. TLS 1.3 would have made this a bit harder.
Next, you have to have a look at the binary. Since a certificate needs a private key, the private key is either stored as a file somewhere on your file system (the easy way) or inside the binary. There is a great question on Security.SE on how to extract a private key from a binary. Since there are many ways how to store a private key, you might need to poke around a little. (If the service used TLS 1.3, you could also use this to search for the certificate.)
Now that you have the certificate and the private key, you can hand those over to your proxy and the server will believe you are the proper service.
However, there is still the matter of certificate pinning. Roughly speaking, certificate pinning refers to the act of saying that a server must respond either with a specific public key in its certificate, or a certificate signed by a specific CA.
In either case, you have the binary, and you have the public key of your proxy's certificate. All you need to do is overwrite whatever the service expects to whatever you have, and all is fine. Alternatively, you could just completely remove the function that does the certificate check and replace it with a stub that always returns that the certificate is valid. The possibilities are endless.
Making an Educated Guess
A lot of software, when it first starts, contacts the developer to see if a new version is available. It wouldn't be that far-fetched to assume that that's what the software does. If you aren't interested in the exercise and just want to see if the service does anything malicious - this is probably what it's doing.