Async indexing process not found


#2

After spending several hours trying to troubleshoot this I am no further along than when originally reported. In an effort to determine if this is a client issue, I have removed the 2.1.15 client completely (used Windows uninstall and deleted any files in C:\program files\UrBackup) and re-installed 2.0.36. This machine, hoover, is still dying with Timeout(1) and now the client log looks like this (only last few lines shown):

2017-06-05 09:33:47: WARNING: Parent directory not found in MFT. Was probably deleted.
2017-06-05 09:33:47: WARNING: Parent of file with FRN 88664617664112585 (Name “f_01bf1b”) with FRN 62487444830343005 not found. Searching via MFT as fallback.
2017-06-05 09:33:47: WARNING: Parent directory not found in MFT. Was probably deleted.
2017-06-05 09:33:47: WARNING: Parent of file with FRN 14355223812898912 (Name “index”) with FRN 62487444830343005 not found. Searching via MFT as fallback.
2017-06-05 09:33:47: WARNING: Parent directory not found in MFT. Was probably deleted.
2017-06-05 09:33:47: WARNING: Parent of file with FRN 162974011515514436 (Name “Report.wer”) with FRN 398568567022333183 not found. Searching via MFT as fallback.
2017-06-05 09:33:47: WARNING: Parent of file with FRN 163255486492225092 (Name “bos_Subordinate_Cert.cer”) with FRN 11258999068474411 not found. Searching via MFT as fallback.
2017-06-05 09:34:09: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-06-05 09:34:09: ERROR: Last error: 10058
2017-06-05 09:37:10: ERROR: Fatal exception code 3221225725 at address 0x00000000772EC8CC
2017-06-06 07:03:02: WARNING: Last record not readable at ‘c:’ - reindexing. Last record USN is 58632081336 FirstUsn is 58763509760 NextUsn is 58800444136
2017-06-06 07:03:02: WARNING: There are 168362800 new USN entries at ‘c:’ - reindexing
2017-06-06 07:04:04: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-06-06 07:04:04: ERROR: Last error: 10058
2017-06-06 07:06:50: ERROR: Fatal exception code 3221225725 at address 0x00000000772EC8CC
2017-06-06 07:14:59: ERROR: Recvfrom error in CUDPThread::UdpStep
2017-06-06 07:14:59: ERROR: Last error: 0
2017-06-06 07:15:52: ERROR: Fatal exception code 3221225725 at address 0x00000000772EC8CC

I must not be the only one having these issues. Anybody have any further troubleshooting advice? Thanks.


#3

Those are crashes. Unforunately it does not create a crashdump. If you manage to create crashdumps I could have a look at them…


#4

Thanks uroni. I assume we just wait for a crashdump? Right now all the crashdump files are empty.


#5

Perhaps one of those methods works: https://blogs.msdn.microsoft.com/cobold/2010/03/01/collecting-crash-dumps/


#6

I’ve managed to capture a few crashdumps. Let me know where I can send. Thanks.


#7

See here: Having problems with UrBackup? Please read before posting Thanks!


#8

Thanks. Dumps just sent as described. Should arrive shortly.


#9

The zipped crashdump and client log are 24 MB and email fails. Is there a upload site where I can place? Thanks.


#10

Looks like there is some kind of loop at C:\Users\maXXXXXX\Documents\TIJ\out\test\TIJ\test\TIJ\test\TIJ

Which client version is this?


#11

Wrong response for this post?


#12

No


#13

If not, then we’re using 2.0.36 as it avoids the async timeouts (at least in some cases). I will exclude: C:\Users\maXXXXXX\Documents\TIJ* and test again.


#14

Exclusion resulted in same timeout.

06/07/17 08:12 INFO Starting unscheduled full file backup…
06/07/17 08:12 DEBUG HOOVER: Connecting for filelist…
06/07/17 08:12 DEBUG HOOVER: Waiting for filelist
06/07/17 08:13 ERROR Constructing of filelist of “HOOVER” failed - TIMEOUT(1)
06/07/17 08:13 ERROR Backup had an early error. Deleting partial backup.


#15

Hmm, looks like a normal, but deep folder structure. I’ll run some tests.


#16

Thank you.


#17

Hi Uroni. Have your tests revealed anything?


#18

Yeah, increasing the stack size for the indexing thread fixes it.


#19

Thanks. What’s the recommended procedure for increasing the stack size or is that done in a patch to the client.


#20

Any thoughts on this? Thanks.


#21

i think he has to patch