selwynreynolds Regular Contributor.
Regular Contributor.

WebInspect scan stops after each audit

I'm running WebInspect 10.4 against an http site using the default scan settings crawl and audit.  It appears that after each audit (currently at 99 of 942) the scan stops. I have to click start/resume to get it started again.  Is there a setting I can configure so it does not stop? Any ideas on why it is stopping - something I can look at? Thank you!

Labels (1)
Tags (1)
2 Replies
Micro Focus Expert
Micro Focus Expert

Re: WebInspect scan stops after each audit

This sounds like the server is no longer responding, the database is full, or your drive space is limited.  At the times of these halts, what if any are the messages in the Scan Log (tab shown at bottom of the UI inside the summary Information Panel)?


In addition to the Scan Log, you could diagnose the outages by inserting an intercept proxy into the scan.  You would Pause the scan, start up the included HP Web Proxy tool or your favored proxy, alter the Current Scan Settings > Proxy panel to use the listener port of that proxy (e.g., and then Resume the scan.  The Web Proxy window should expose the traffic issues.  Reverse this configuration when you no longer want to monitor with Web Proxy.

The most common cause of halting scans is that the server is not responding to an adequate number of HTTP Requests and so WebInspect is assuming that the server has gone off-line.  The Requestors panel within the Scan Settings sets the acceptable number of Consecutive timeouts.  Some users think disabling feature this will fix their issue, but that would only cause WebInspect to continuing firing Requests into the ether with no responses coming back ever, so really not good.

One of the first items to try for the timeouts issue would be to increase the Timeout count (20 seconds) found on the Requestor panel of the Scan Settings.  You might also try using lower thread counts.  The same Requestors panel is where you can see the default is to run with 5 threads Crawling and 10 of Auditing.  Be aware that lowered thread counts means a longer scan duration, so it is a bit of a balancing game.

In some rare cases, the target application might be dropping the scanner's connections based on some 3rd-party protective filter or similar IPS-like feature, if it notices that WebInspect is maliciously fuzzing its inputs.  You would need to discuss a correction for that with the IPS/protective team on your network.


Under the Edit menu > Application Settings > Directories panel of WebInspect you can locate the paths where the scans and logs are written.  Are they at risk of limited free drive space?


If using SQL Express, you should have up to 10GB of storage per scan.  Long ago we used to run into this as an issue before SQL Express 2008 R2 came along, because the limit used to be 4GB per scan with 2005 and earlier releases of Express 2008.  If you are using a Standard or Enterprise edition of SQL Server than this would not be the correct item to research, as those afford a theoretical unlimited scan size.

-- Habeas Data
Micro Focus Fortify Customers-Only Forums – https://community.softwaregrp.com/t5/Fortify/ct-p/fortify
selwynreynolds Regular Contributor.
Regular Contributor.

Re: WebInspect scan stops after each audit

Hi Hans,

Thanks for your reply!  This is the message in the scan log at the bottom:

5/31/2015 2:17:18 PMInfoStop Requested, reason=ConnectivityProblemEventHandlerArgs:

I have plenty of memory for SQL Express and the log folders. It keeps scanning once I hit resume.  It just seems odd that it stops after each audit (at least that is my assumption as the audit # has increased by 1 each time it is stopped). It would seem odd to me also that connectivity is lost after each audit. Maybe it is just coincidental that the audit # has increased by 1 each time.  connectivity is obviously resumed when I click resume.

I will try increasing the time out on the Scan Setting Requestor panel when I can scan again later today.



The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.