This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I am getting "Run Time Error, The application has requested the Run Time to terminate the application in a unusaull way. Please contact the application administrator" while it is capturing the pacjets approxmiately after two minutes.

I am running WireShark on VMware Windows Server 2003 SP2. Any idea?

asked 14 May '12, 15:52

Younisg's gravatar image

Younisg
1111
accept rate: 0%

I have been getting this a lot too in a VM environment with Server 2008 R2. I have 4GB of memory provisioned, and i even went to the length of setting Wireshark to roll files every 10MB (which correct me if i am wrong, but that limits the memory buffer of the capture to 10mb right?) The capture always fails within about 30 minutes, and the output file is never more than about 5MB in size (this particular crash, the output was 900kb). I can repeat this at will, no matter how I execute wireshark it always crashes within 30 minutes.

(24 Oct '12, 06:04) Jeff Meden

(which correct me if i am wrong, but that limits the memory buffer of the capture to 10mb right?)

That will not limit the amount of RAM wireshark needs to load, to "store" and to dissect the packets in memory. So, the longer you run Wireshark, the more memory it will allocate. Depending on the amount of bytes/s you will run out of memory in 5,10,20,30 minutes.

(29 Oct '12, 04:59) Kurt Knochner ♦

As far as I understood an explanation by Anders Broman at Sharkfest 2012 Wireshark does not store packet bytes in memory but always reads only the currect selected frame from disk. So the memory problems are caused by meta data structures, not packet bytes, and that explains why tons of small packets get you into trouble much sooner than less but huge packets.

(29 Oct '12, 06:11) Jasper ♦♦

From above it's not clear which versions are affected we have had bugs with memory leaks in various versions so it's possible there is a bug.

But it is also a known problem that Wireshark will run out of memory eventually when the trace reaches some size. As wireshark uses memory to keep state of various protocols, conversation data, reasembly data some of the column strings. A structure per-packet (frame data) protocol-per-packet-data etc. Your milage depends of the protocol mix in the trace, your preference settings etc. So giving a size estimate is impossible.

(30 Oct '12, 02:31) Anders ♦

For long term captures or rapidly growing trace files it's recomended to use dumpcap possibly creating new files at set size as dumpcap does not exhaust the memory it only writes to file witout any analysis of the packet content.

(30 Oct '12, 02:33) Anders ♦

As far as I understood an explanation by Anders Broman at Sharkfest 2012 Wireshark does not store packet bytes in memory but always reads only the currect selected frame from disk.

I wish there was a decent description of the internal data structures and the overall "data/instruction flow" within Wireshark ;-))

BTW: I was not able to find that presentation. @Anders, would you mind to post the link?

EDIT: Oh, you said "explanation". That possibly means a personal conversation and not a presentation, right? Anyway, the internal structure of wireshark would make up a good topic for the next sharkfest :-)

Thanks
Kurt

(30 Oct '12, 03:21) Kurt Knochner ♦

Correct, it was a personal talk between me and him. But good idea... maybe we can convince Anders to do a talk about those things next Sharkfest :-)

(30 Oct '12, 03:26) Jasper ♦♦

Good idea, however I think you will have to convince him, as I don't know him personally ;-)

(30 Oct '12, 05:26) Kurt Knochner ♦

There must be something more going on here. I saw this error on a Windows Server 2008 R2 machine with 32 GB of ram, after less than 30 minutes of capturing SNMP traffic (filter "udp and port 161") and it was just watching a local application that transmits at most 4000 packets/hour (yes barely 1 packet/sec). What more can I do to investigate the cause?

(30 Oct '12, 19:10) Jeff Meden

What version are you running? can you try a development build?

(30 Oct '12, 23:03) Anders ♦

Test with 1.8.0 RC2:

Problem signature: Problem Event Name: APPCRASH Application Name: wireshark.exe Application Version: 1.8.0.43337 Application Timestamp: 4fdf7a06 Fault Module Name: wiretap-1.8.0.dll Fault Module Version: 1.8.0.0 Fault Module Timestamp: 4fdf7918 Exception Code: c0000005 Exception Offset: 0000000000012633 OS Version: 6.1.7601.2.1.0.274.10 Locale ID: 1033

(02 Nov '12, 07:28) Jeff Meden

I'm afraid that we can't do anything with that information. If you're sure you're not just running out of memory, please open a bug on Bugzilla and attach the capture file that causes the issue. If the capture contains traffic of a sensitive nature you can mark the bug private to restrict access to the core developers.

(02 Nov '12, 09:43) grahamb ♦

You can get development builds from here http://www.wireshark.org/download/automated/ Test with 1.8.0 RC2: is actually pre 1.8 i.e a release candidate (RC) to 1.8.

(02 Nov '12, 11:27) Anders ♦
showing 5 of 13 show 8 more comments

sounds like an "out of memory" error. Please check this:

  1. how much RAM does your system have?
  2. how much traffic (approx. bytes) did you capture?
  3. What kind of traffic has been captures (e.g. mainly HTTP)?
  4. Please check the Eventlog for any detailed error messages

If you have that information, you'll either figure out yourself it's a memory problem, or you're welcome to post the information here for further discussion.

Regards
Kurt

permanent link

answered 15 May '12, 00:43

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

I have 2GB RAM. I had most LDAP traffic becasue server I am running on it is Domain Controller. Also after shutting down I do not see any logs in Event Logs.

(15 May '12, 07:31) Younisg

2 GByte is not "that" much.

  • How did you capture?
  • With or without a capture filter ("port 389")?
  • How many packets did you see (approx.) before wireshark was killed.

I still believe it's a memory problem.

Anyway, you'd better sniff in front of the server on a mirror/monitor port (of your switch) or with a TAP, see here: http://wiki.wireshark.org/CaptureSetup/Ethernet

(15 May '12, 07:50) Kurt Knochner ♦

Same here Wireshark 1.8 on Windows Server 2008 R2 with 2GB Memory.

"Runtime-Error after short period of capturing low volume data."

I can understand that memory can be/is an issue but there should be a warning or stopping the capture process (and then an info dialog).

But crashing is not a nice way to exit an application as it looks kind of uncontrolled behavior..

Regards, Oliver

(28 Jun '12, 02:36) Posbis

You can file a bug report at https://bugs.wireshark.org/bugzilla/ with a link to this question.

Regards
Kurt

(28 Jun '12, 03:02) Kurt Knochner ♦

Catching "Outof-memory" and doing something sensible is not as easy as it may seem. Earlier glib versions did not have a way of testing if memory is available. And more memory may be required to do a graceful close down.

(30 Oct '12, 02:21) Anders ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×1,620
×193
×14

question asked: 14 May '12, 15:52

question was seen: 9,170 times

last updated: 30 Jan '13, 00:12

p​o​w​e​r​e​d by O​S​Q​A