Visual C++ Runtime Library Error "The application has requested the Runtime to terminate it in an unusual way." when trying to look at Statistics/IO Graph and Flow Graph

This issue was migrated from bug 9062 in our old bug tracker.

Original bug information:

Reporter: Paul Ybarra
Status: RESOLVED WONTFIX
Product: Wireshark
Component: GTK+ UI
OS: Windows 7
Platform: x86
Version: 1.10.0

Paul Ybarra said:

Build Information: ersion 1.10.0 (SVN Rev 49790 from /trunk-1.10)

Copyright 1998-2013 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 5 2013), with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, with 3242MB of physical memory.

Built using Microsoft Visual C++ 10.0 build 40219

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

Wireshark appears to work for all other functions. The error occurs only when trying these two functions. It does not appear to be related to size of capture. This appears even for just a few lines of captured traffic.

In our environment we have various versions of Visual C++ and we have removed them to see if there are conflicts but this has not resolved the issue.

There are some instances of Win7 in our environment where the issue does not manifest.

We have remimaged systems with Win7 and reinstalled Wireshark and still see the problem.

Is there something I can enable to troubleshoot this problem?

Thanks for your help.

Paul Ybarra

added oswindows uigtk version1.10 labels

Paul Ybarra said:

Wireshark terminates after these errors and forces close.

Paul Ybarra said:

Output from the Event Log:

Faulting application name: Wireshark.exe, version: 1.10.0.49790, time stamp: 0x51af7ca6 Faulting module name: libcairo-2.dll, version: 0.0.0.0, time stamp: 0x508da16e Exception code: 0x40000015 Fault offset: 0x0007ea30 Faulting process id: 0x70 Faulting application start time: 0x01ce9e7847a28b69 Faulting application path: C:\Program Files\Wireshark\Wireshark.exe Faulting module path: C:\Program Files\Wireshark\libcairo-2.dll Report Id: 9680544e-0a6e-11e3-a5a0-0025b3110ddf

Evan Huus said:

Hi Paul, yes there is probably something you can do :)

We have seen varying reports of problems like this, but none of us have ever been able to reproduce them. Since it sounds like you have some sort of development setup (multiple versions of Visual C++), if you could get a stack trace of the crash for us that would be extremely helpful.

Thanks, Evan

Paul Ybarra said:

Evan,

Can you send me instructions on how to do this? I do not have an VC++ development environment setup.

Thanks,

Paul

Graham Bloice said:

Paul,

There are two ways of generating the stack frame:

1.  The user has a Windows debugger (e.g. Visual Studio or WinDbg) and can get the stack trace from the debugger.  The user must have the pdb's and let their debugger know where they are.

2.  The user generates a memory dump (basically an image of the faulting process) and forwards that to someone who has a debugger and the pdb's and they can see the stack trace and (if a full memory dump is provided) poke around inside the process image which is frozen as if it had hit a breakpoint.

The memory dump can be generated in a few ways, and there are a few versions of the dump that only include the stack of the faulting thread, stacks for all threads or a full memory image.  Obviously the full image can be quite big, especially if the fault was caused by the process running out of memory but it does zip up a bit.

To create a full dump file on Windows 7, using Task Manager, switch to the Processes tab, right click the offending process and select "Create Dump File".  When the dump is complete, a further dialog will show the path to it.

Zip up the dump file and attach it to the bug.  Note that the dump file will include some info such as the logged on user name, the computer name and the domain the computer (if any) belongs to.  In addition, if you have added SSL master keys to Wireshark, then they may be present in the dump file.

Paul Ybarra said:

Evan,

Further testing revealed a certain condition where these VC++ Runtime Library Errors occur. Whenever we get to desktops with Wireshark using standard Windows "Remote Desktop" (i.e. mstsc), the VC++ run time error occurs. When logging  onto the workstations directly (i.e. not remotely), this VC++ Runtime Library Error does NOT occur. This leads me to believe that there are some local security policies that are getting enforced in my environment that are preventing Statistics/IO Graph and Flow Graph from working.

If I understood how these GUI components rely on windows local security policies, I could possibly look for a work-around. Conversely, I don't think that these two component should have any higher security requirement compared to capturing packets, which is working fine remotely. In otherwords, I think that a security policy is being used that should actually be ignored by the application.

Do you know what security policy could be preventing these reports from displaying for remote desktop users? If we have no clue, then I can perhaps send the dumps you requested to provide more information.

I have tested this case on several remote systems and physical systems and the results are consist.

Thank you!

Paul

Evan Huus said:

That's very odd. As far as I know, Wireshark relies on third-party libraries (GTK, Pango, Cairo) for most of its graph rendering, so if that is the problem then I suspect there isn't much we can do at our end.

Sorry I can't provide more insight, I'm not too familiar with that part of the code. Somebody else might be able to help more.

Christopher Maynard said:

(In reply to Evan Huus from comment #‍7)
> That's very odd. As far as I know, Wireshark relies on third-party libraries
> (GTK, Pango, Cairo) for most of its graph rendering, so if that is the
> problem then I suspect there isn't much we can do at our end.

Wireshark no longer supports the GTK+ UI, but has switched to the Qt UI. If the problem still exists with the GTK+ UI, then it won't be fixed, so I'm closing the bug. If the problem can be reproduced with the latest stable Wireshark version using the Qt UI, then feel free to reopen the bug.

closed