Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: hashcat 0.46 memory trouble in cmd file?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Today I was running hashcat 0.46 via a batch/command file with a list of 52 rules, and it seemed to be a culprit in crashing my 16 GB Windows 7 Home Premium system. I've run that same batch/command file many times, with past versions, against more hashes, with no problems, so it may a quirk with my system at this point in time, and nothing to do with hashcat.

When it got to only line 9 of 52 lines of rules, the system event log reported this:

Log Name: System
Source: Microsoft-Windows-Resource-Exhaustion-Detector
Date: 7/20/2013 6:33:51 PM
Event ID: 2004
Task Category: Resource Exhaustion Diagnosis Events
Level: Warning
Keywords: Events related to exhaustion of system commit limit (virtual memory).
User: SYSTEM
Description:
Windows successfully diagnosed a low virtual memory condition.
The following programs consumed the most virtual memory:
hashcat-cli64.exe (3780) consumed 40,719,126,528 bytes,
svchost.exe (792) consumed 352,260,096 bytes, and
mysqld.exe (1588) consumed 192,524,288 bytes.


There is a variety of software running, and I have done some hardware changes, recently, too, so this may be a fluke. E.g., my page file may have already been corrupted before this.

But, I want to mention it here, in case anyone else has a similar crash.
Looks like a memory leak.
What was the exact version of hc ?
There is a program that may have been causing some system troubles, which I've uninstalled.
If a week goes by without trouble, then I'll re-try the batch file running hashcat.
After having cleaned up my system a bit on the weekend, including re-building the page file, and having uninstalled a suspect program, I was going to kill two birds with one stone by running that group of rules first in hashcat-plus, recording the elapsed time, then running the same group, via the equivalent batch file, in CPU hashcat, to compare the timings.

Hashcat-plus took 36 minutes, so I began the batch file for hashcat, which I've used many times before without problems, but walked back from the kitchen and saw that 98% of my system's 16 GB of RAM was being used. Normally, typical usage is around 12%. Only diagnostics use near 100% if I chosen to do so.

Neither hashcat have ever used a lot of memory.

I'm not sure why hashcat-cli64.exe v 0.46 in a batch file, reading a list of many rules, all of a sudden acts funny.

It still may be some new problem with my system, but everything else runs normally.

I may try some testing with some Sysinternals utilities, on the weekend, but wonder if any of the programmers would have a way of determining if there is a memory leak or not.
Hey.
Rest assured that devs are already investigating this possible memory (RAM) problem.
Do you think that you can give more details on which parameters you use and how large (roughly) your dicts/rule files etc are? Also it would be great to know how your batch file really looks like, what exactly changes in your batch file from line to line (iteration to iteration)? The input rule file? The dict etc...
You say 52 rules... do you mean 52 files w/ rules or 1 file with 52 rules? If many files... what happens if you "concatenate" them (sort -u *.rules > all.rules or similar).

I think we already spotted some (memory) problems, so next version will improve things. But it would be great if we could double-check that w/ your exact cmdline.

BTW: It would be great to have this on Trac. Maybe you can describe the problem there too.... otherwise I will do soon.

Thx
The guts are:

:: run the batch of rules
FOR /F %%G IN (rules-batch.txt) DO (call :main %%G)


The command line used starts off with:

hashcat-cli64.exe -n 4 -c 128
Even after uninstalling the program I thought was at fault for my system wierdness, I still had more crashes.

The real problem may've been updating to NVIDIA's 320.49 driver. See the thread "NVIDIA driver 320.49 WHQL freezing my PC" at:
https://forums.geforce.com/default/topic...ing-my-pc/
Running some tests tonight, I found that the problem was actually due to using the new option: --debug-mode=3.
good find. can you do a trac ticket?
No, I haven't set myself up there, as I'm never quite sure if what I find is really a hashcat problem or something to do with my test environment.

I'd prefer to post a problem here, and let someone more qualified confirm the problem, then make a more formal trac out of it.
Pages: 1 2