oclHashcat-plus 0.12 interface freeze issue...
#1
After I started using the latest version of oclHashcat-plus, I have noticed that the interface becomes non-responsive after a while. It's still crunching away trying to find passwords, which I can check the pot file to verify, but I can't pause, bypass, check status and so on. The only thing I can do is to close the window, or wait until a particular task has finished (eg. moving on to next dictionary) when it becomes responisve as normal again. But it will freeze up again after a while. I never had this issue with older versions. Any ideas?

I'm running Windows 7 x64. 1 x hd6950 with 12.8 drivers.

Thanks.
#2
I've observed this issue either on my Kubuntu 12.04, Catalyst 12.8.
#3
I've also had this issues when trying to crack WPA -m 2500, screen goes blank and no response, have to power-cycle. Noticed the WPA speeds are slower with v0.12 that they were with v0.10 rc1 and v0.10 was stable and did not crash.

v0.10: 405.3k c/s
v0.12: 398.5k c/s
#4
Try a lower -n value. That's what it's for.
#5
(01-02-2013, 09:45 PM)epixoip Wrote: Try a lower -n value. That's what it's for.

I'm not sure if you are replying to blandyuk's speed issue or to the original non-responsive interface. In case of the latter then unfortunately lowering the -n value won't help. Sometimes when running dictionaries oclHashcat won't run at full speed, which is normal. And even during these times the interface has become non-responsive. So whatever the reason, it's not because the GPU is too busy or similar issues.

Oh, by the way, I forgot to mention that just before it happens I have noticed that just for a second the GPU slows down and then immediately picks up again. And if for example I then try to check the status in oclHashcat nothing will happen.
#6
(01-02-2013, 06:17 PM)blandyuk Wrote: I've also had this issues when trying to crack WPA -m 2500, screen goes blank and no response, have to power-cycle. Noticed the WPA speeds are slower with v0.12 that they were with v0.10 rc1 and v0.10 was stable and did not crash.

v0.10: 405.3k c/s
v0.12: 398.5k c/s

There was no change from v0.10-rc1 to v0.12
#7
For the non-responsive interface, I get that as well. You can notice also that it happens only at the end of the runs. It might be a feature to allow mixed GPUs to wait for each other when they are done working. However I get the same non-responsive interface with a single GPU so maybe it's a necessary precaution to block the user interface while the program is cleaning up stuff. Only Atom can answer that one.
#8
It happened to me once when I had an attack running for more than 30min I think. It just didn't respond anymore but it was working. Its a rarely thing.
#9
I've had this happen as well on ubuntu 12.04 and cat 12.8 with latest version of plus.
#10
I guess this is somethign that is happening when its comes to the last block of the calculation. Depending on -n size, the first block can be the last block so it just looks like its something different. Just for the test please run you test with -n 1 and take a look at the progress percentage when it happens the first time. Is it the same as if you would not run it with -n 1?