v11 - host lookup failure now shows as "Error in the application"

[DanielJ]

I'm just starting out with v11, and my test job failed with the previously unseen and somewhat alarming "Error in the application". Checking the logs it turned out that it was a missing hosts entry on a proxy. Previously this would have put "No such host is known" in the session log (visible in the gui), and the job log did show the usual messages. Has this new error message replaced any other previous more specific messages? This is just a small detail, but it would be good to get something a bit less generic to minimize the need to dig around in logs.

[Gostev]

No, we did not replace any error messages around this functionality in V11, so this would need to be investigated closer.

[DanielJ]

I sent in the logs in ticket 04861052.

[FrazierCO]

I just encountered the same error message. A generic search on the documentation does not reveal any explanation of the error message: "Error in the application"

The hunt continues.

[veremin]

Hi, Howard, what is your support case Id for this issue? Thanks!

[FrazierCO]

I have not opened a support case on this issue yet. I am evaluating the product and have a trial license at this point. I must say, I've encountered dozens of various error messages and some are apparently 'new' and there is no documentation. "Error in the application" is just an example. It appears that you have a very robust product upgrade schedule and documentation does not always match the product. I'm about three or fours days into the support case I opened (Veeam Support - Case # 04888748) when I first attempted to install the B&R product to test it. I get one minor reply from support each day so it will take a long time at this rate to work through the error messages.

[Mildur]

"Error in the application" is just an example.

This looks more like a windows application crash message of the software itself and not a „error message from inside Veeam“.

Veeam cannot produce error messages for this cases when veeam is crashing on a unstable windows machine. The same goes for every application on a windows machine. This needs further debugging on a very deep level.

[FrazierCO]

This looks more like a windows application crash message of the software itself and not a „error message from inside Veeam“.

Veeam cannot produce error messages for this cases when veeam is crashing on a unstable windows machine. The same goes for every application on a windows machine. This needs further debugging on a very deep level.

I understand that if Windows is generating an error message due to an OS issue, Veeam might not be able to capture that, but I don't believe that is the situation I am experiencing because the error message is in a list of status messages generated by Veeam (see list below). In this particular case, I have several other backup jobs that are completing successfully.

Code: Select all

7/5/2021 4:33:23 AM :: Job started at 7/5/2021 4:33:20 AM  
7/5/2021 4:33:24 AM :: Building list of machines to process  
7/5/2021 4:33:33 AM :: VM size: 127 GB (124.4 GB used)  
7/5/2021 4:33:33 AM :: Changed block tracking is enabled  
7/5/2021 4:33:37 AM :: Failed to pre-process the job Error: Error in the application.  
7/5/2021 4:33:41 AM :: Error: Error in the application.  
7/5/2021 4:33:44 AM :: Job finished with error at 7/5/2021 4:33:44 AM

[veremin]

We need to check debug logs and actual setup, so kindly reach our support team - users on a trial license are eligible for Standard support during their official evaluation period. Thanks!

[JaySt]

had the same error today with a up2date v11 install trying to backup a single VM on a standalone 2019 HV node. checked everything DNS related.
I initially thought it could have something to do with the fact manual checkpoint creation also failed on the HV node when i tried to do so using the Hyper-V manager on that host ("Production checkpoints cannot be created" message). I fixed that by checking all boxes for the integration services for that VM in the settings. checkpointing is fine now, but still the same error when the Veeam backup starts. It fails with the "error in application" message right after the task of creating a checkpoint (according to the job progress window), but a checkpoint is never created by veeam it seems. So it must be something that fails right before checkpoint creation.

I might be asking support for help as well here. The logs i've looked at did not help me much either.

[veremin]

Correct, opening a ticket is a preferable approach here, as without it and without debug logs there is not much we can do to dig the issue deeper. Thanks!

[JaySt]

just saw a log entry indicating connectivity issues from HV node to the VBR server on port 2500. so seems connectivity related after all! will report back when i know more.

[JRTCo]

Same error here. Nothing obvious causing the issue.

[Natalia Lupacheva]

Hello @JRTCo,

Kindly share your Support case ID.
Currently we don't have any universal solution, so your logs analysis is required here.

Thank you!

[JaySt]

just saw a log entry indicating connectivity issues from HV node to the VBR server on port 2500. so seems connectivity related after all! will report back when i know more.

In my case the connectivity problems were cause by a firewall. The Windows HV node was not allowed to communicate back to the VBR / Repository server on ports like 2500.
What i did to resolve, and was compatible with the firewall policy in this environment, was to configure the HV node to "listen" mode for these ports as described here: https://helpcenter.veeam.com/docs/backu ... ml?ver=110
"Run server on this side" enabled, and off we went.

So that confirms the the cause of the error in my case. I did run into this in previous veeam versions, and i think i saw better error-reporting about these kind of connectivity problems in the past. I was a bit off when i just saw "error in the application" as the only clue when it was purely connectivity related in the end.

[jmackenzie]

@DanielJ did you get to a resolution for the "Error in the application" error?

[HannesK]

Hello,
and welcome to the forums.

According to support comment, the most likely reasons are:
- a proxy can't contact ESXi host;
- a proxy can't connect to a repository

for any further investigations, please open a support case if you see that issue.

Best regards,
Hannes

[DanielJ]

@jmackenzie Only that it was (now) a known problem and being worked on in an internal ticket.

[Cragdoo]

Just to add to the conversation/knowledge. I had the same error message, the fix? My newly created linux proxies couldn't resolve my vcenter/esxi hosts ...so it was DNS

[hunter]

Hello
@Cragdoo
if you add dns record for ESXi host in to host file - windows\system32\drivers\etc\hosts (name IP FQDN ) on veeamB&R server and repository if you have windows repository.
This solution fixed the problem

[adelamora]

Hosts file did not resolve the issue for me, even though both the server name and FQDN were listed. I had to change all server names in VBR to be FQDN. I used this to change the name: https://www.veeam.com/kb1905

[nopking]

Got this message tonight after things have been running smoothly for infinity days...

copy job, got 3 of the 11 or so VMs off and then started throwing error in the application
jumped into the backup server and sure enough it can't resolve the name "FH-RAID" after two or so years. I checked and FH-RAID has died, not pingable.

So destination server down also throws "Error in the application"

[Anguel]

"Error in the application" ("Fehler in der Anwendung" in German) on simple file copy jobs using a simple NAS share with hardcoded IP, e.g. \\192.168.0.9\MYSHARE as source. I never had such problems before...

BTW, many other annoying errors after v11 update, never experienced so many in any of the previous versions. Also had to recreate some repositories for other jobs because of other strange errors like "Agent failed to process method {Stg.AddKeySets}" and others. Unfortunately I am too busy at the moment to discuss all of these with Veeam support. Really hope for fixes soon.

[Gostev]

Unfortunately, for these fixes to arrive any time soon, Veeam support needs to first investigate what is causing them in your environment (Veeam bugs or some environmental issues). Overall, all the common V11 bugs have been fixed long ago already with cumulative patches, what is left now are mostly environment-specific issues...

[CrispyPancake404]

Hey just chiming in,

We also see this problem have had no luck identifying so know your not alone, logs show nothing and the issue is new in V11 with no changes to the windows proxies since V10. Issue is also not DNS related, we hardcode everything.

[veremin]

Can you provide us with the number of support ticket within which this issue was investigated? This way we can ask QA team to check the case and find the root cause of the behaviour experienced. Thanks!

[Anguel]

Overall, all the common V11 bugs have been fixed long ago already with cumulative patches, what is left now are mostly environment-specific issues...

Hmm, I am a bit confused. Is it possible that Veeam simply dropped file copy job support from simple NAS SMB shares? Looks like I cannot enter a source path like \\192.168.0.10\MYSHARE anymore, I must select a server instead but looks like I must have a full Linux server running according to https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[veremin]

Are you still talking about the issue this thread is about, or is this an off-topic? If so, please create the dedicated thread instead. Thanks!

[Gostev]

P.S. You can register a file share as a data source directly, without any need for Linux hosts.

[Anguel]

Are you still talking about the issue this thread is about, or is this an off-topic? If so, please create the dedicated thread instead. Thanks!

Well, it looks like this was what caused the "Error in the application" error in my case. I had an old file copy job that accessed an SMB file share on a NAS and worked fine up to v10. In v11 it suddenly failed with "Error in the application" for every file being copied because as far as I understand file copy jobs cannot be created for SMB shares anymore. As Gostev suggested, now I registered an SMB share in inventory and replaced the file copy job with a normal backup job that seems to work fine now. Hope this helps.