hashcat deletes restore on CL_OUT_OF_RESOURCES

[BotPass]

From time to time I get CL_OUT_OF_RESOURCES (on Windows). If this occurs then hashcat deletes the restore file and exits. Thus I am not able to recover from a time (shortly) before the error occurs.
Am I doing something wrong? Or is this intended? Is there a way to get around to start from the beginning?

I do not know why I'm getting this error or how to find out the reason. I'm aware of https://hashcat.net/wiki/doku.php?id=timeout_patch and this is done months ago. Before this registry key was set, hashcat warns about it. After setting the key hashcat does not warn any more but the error still occurs. It could happen just minutes after starting or after hour/days. It is also possible that it took a month before there is another CL_OUT_OF_RESSOURCES (hashcat is not running all the time).
I reinstalled different version of driver and also test different cards (also using two or only one).

Because I do not know why it happens, how to prevent it and how to prevent hashcat from deleting the restore file I only see a workaround in a task periodically copying the restore-file out of the hashcat folder. Is there a better way?

Thank you in advanced!

I already searched for the reason of CL_OUT_OF_RESSOURCES (e.g. it occurs on buffer out of index and also as a dummy error) and here on the forum but did not find anything helpful . If I missed something, I'm sorry.

[philsmd]

what is the final status you get?

Code:

Status...........: Exhausted

It would also make sense to know the exit code of the process/application

[BotPass]

Thank you for your response.

Indeed the status is exhausted even though "Progress" and "Restore.Point" is below 100.00%. Up to now I did not log the return code thus there is nothing to tell. I modified it and give it another try, but as a result of the unpredictability I do not know when I can tell it.

Dunno if this helps:
I looked up some logs and in all that cases the first error was written on the same line as "[s]tatus" and it was written to occur in "clWaitForEvents", then another clWaitForEvents and four times "clEnqueueReadBuffer", before the "Status.[...]: Exhausted" line.

[philsmd]

my current guess is that the problem is that the status is set to exhausted incorrectly (in this particular case because of the previous error) here:
https://github.com/hashcat/hashcat/blob/...#L267-L275

It would be interesting to know what the previous status_ctx->devices_status value is (before it was automatically/forcefully set to exhausted).

of course in case of exhausted we do not need a restore file anymore, therefore it is deleted... but the problem is that the status shouldn't be set to exhausted in this case.


The main problem (i.e. why you get the original error message about the resource problem) would be also interesting to track down... but I would suggest investigating one problem at a time and I'm also not aware of any other user randomly getting those resource errors even if the timeout patch was applied (which might inidicate a problem with your specific setup/drivers/hardware etc).

[atom]

We've fixed this with commit 82457d290469db2b125e6ae3ebcc922aaf7f9235

New beta is up for test at htts://hashcat.net/beta/

[BotPass]

Thank you for the responses.

I will have a look at it.

EDIT:
Just one followup to let you know.
The fix seems to work. Even though I cannot distinguish the returning code between opencl error or another error in a script, it helps as a work around for the OPENCL_OUT_OF_RESSOURCES. I could not find the reason for those.
Additionally it seems that under (unknown) rare circumstances hashcat print the last status before exit, but did not exit even after hour. Strangely it could not be killed by taskmanager and the system has to be rebooted. This happens not only to the one system with CL_OUT_OF_RECCOURCES but also on my second one.