0xC0000005 Access Violation

Hi all,
I realize there are quite a few threads with a similar Crash report and I believe I have read them all, but I hope someone can help me out here.
In this particulair program I customized some GUI stuff, mainly gauges and a couple of static bitmaps on the background. This means the 'backbone' runs on various other projects. Still for some reason it keeps crashing with a 0xC0000005 Access Violation. The Exception is at EIP 0x07E504A3. The program runs on a server computer to which 4 tablets (that run Windows 8.1) connect using an application reference. This setup proved very stable in various projects and hardly ever changes.
The problem is that the server pc (running Windows 7 pro, admin user) crashes about once every day with this report. My customer has swapped the PC for a brand new one, but it still crashes every day.
I have ran the application over here on a Windows 7 machine, with the same setup, but it seems to run just fine.
Any help would be greatly appreciated.
Chris
Attachments:
ni_support.zip ‏77 KB
errorlogs.zip ‏846 KB

continued here
(typically users should not respond in the threads marked as duplicate, but since the discussion continued in the other thread, let's keep this thread closed instead)
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

0xC0000005 Access Violation in cvirte.dll (SetWindowsErrorMode?)

Hello,
We will occasionally see a crash with our CVI LabWindows based 2010 SP1 application, a 0xC0000005 Access Violation exception thrown from within cvirte.dll. The app is working primarily from a spawned thread when the crash occurs. I've been able to get it consistently on a Win7 x64 VirtualBox VM and have some data that may be of use if someone there would like to investigate.
When I track down the location of the instruction pointer (work below) it seems to be in the "SetWindowsErrorMode()" function (at least going by the exports in DependencyWalker):
1. The IP is 0x687B5F1C at the time of the crash.
2. The base module address for cvirte.dll is 0x68420000, so the IP is 0x395F1C bytes into the DLL.
3. Using DependencyWalker on cvirte.dll and sorting by entry point indicates that the IP is inside of "SetWindowsErrorMode()" at 0x003938D0, which comes before "MinimizeAllWindows()" at 0x003984B0.
Coincidentally, this crash happens in CVI 2013 F1 as well, the offset within "SetWindowsErrorMode()" is a bit different (0x264C past entry in 2010 SP1, 0x2D0C past entry in 2013), but locally the code looks the same in my VS2010 disassembler:
CVI2010 SP1
*Address *Code Bytes *Instruction
687B5F02 89 17 mov dword ptr [edi],edx
687B5F04 8B 48 5C mov ecx,dword ptr [eax+5Ch]
687B5F07 89 78 6C mov dword ptr [eax+6Ch],edi
687B5F0A 89 4F 04 mov dword ptr [edi+4],ecx
687B5F0D 89 58 5C mov dword ptr [eax+5Ch],ebx
687B5F10 C7 40 60 00 00 00 00 mov dword ptr [eax+60h],0
687B5F17 5E pop esi
687B5F18 85 DB test ebx,ebx
687B5F1A 74 09 je 687B5F25
687B5F1C 8B 13 mov edx,dword ptr [ebx] <--- CRASH
CVI2013 F1
*Address *Code Bytes *Instruction
687CA2B2 89 17 mov dword ptr [edi],edx
687CA2B4 8B 48 5C mov ecx,dword ptr [eax+5Ch]
687CA2B7 89 78 6C mov dword ptr [eax+6Ch],edi
687CA2BA 89 4F 04 mov dword ptr [edi+4],ecx
687CA2BD 89 58 5C mov dword ptr [eax+5Ch],ebx
687CA2C0 C7 40 60 00 00 00 00 mov dword ptr [eax+60h],0
687CA2C7 5E pop esi
687CA2C8 85 DB test ebx,ebx
687CA2CA 74 09 je 687CA2D5
687CA2CC 8B 13 mov edx,dword ptr [ebx] <--- CRASH
I have dump files (mini, or mini+heap) for both builds if it would help.
This bug seems semi-similar to the thread "Is InstallPopup not threadsafe?":
http://forums.ni.com/t5/LabWindows-CVI/Is-InstallPopup-not-threadsafe/m-p/716822/highlight/true#M359...
Just for posterity, I'll add the data for the 2013 build. IP is 0x687CA2CC, DLL Module address is 0x68420000-0x68A28000, so offset is 0x3AA2CC. "SetWindowsErrorMode()" enters at 0x003A75C0 in this dll, and "MinimizeAllWindows()" is at 0x003ACB20.
Thanks-
Baker

Hi Kelsey,
Apologies for the long response time, I didn't receive a notification for your post.
> What does your application do?
Our application is used in this context to setup and run our vehicle simulations on a Windows based PC.
> And, what is it doing at the time of the crash?
At the time of the crash a simulation is being launched and run on another thread from the default thread pool like this:
CmtScheduleThreadPoolFunctionAdv (DEFAULT_THREAD_POOL_HANDLE,
sRun,
NULL,
THREAD_PRIORITY_NORMAL,
NULL,
EVENT_TP_THREAD_FUNCTION_END,
NULL,
RUN_IN_SCHEDULED_THREAD,
&sThreadFuncId);
That spawned thread will load a simulation DLL, read some data as input, run the simulation, output the results, then close the DLL.
As I noted earlier, I couldn't get it to happen on my desktop, but I could get it on the VM when I used a very slow storage device for the I/O of the simulation (a slow thumb drive attached to the VM). My boss was seeing the issue on his virtualized PC on his Mac, typically only when he used a slower storage device as well (network storage for example).
> When you reproduce this issue in 2010 and 2013 f1, are you using the same computer or using different machines?
Both of these crash dumps were produced on the virtual machine as described.
> For each dump file, which version of LabWindows/CVI were you running? You can find the version number by selecting Help»About LabWindows/CVI within LabWindows/CVI. Which version of cvirte.dll do you have? This will be located in System32 and/or SysWOW64.
The development environment installed was CVI 2010 SP1. So the 2010 dump was just using the runtimes bundled with that installation. I then installed the 2013 F1 runtimes to see if the same issue persisted.
It's possible I did a clean install with the 2013 F1 dev environment, I will double check this tomorrow when I have access to the virtual machine.
Thanks for looking into this--
Baker

InitCVIRTE generates error message "Unhandled exception in "MyApp.exe": 0xC0000005: Access violation reading location 0x00000000."

Hi,
I have converted a LabWindows CVI project to Visual Studio 2005. When I start the application i debug mode I get the message "Unhandled exception at 0x685662ba in EE352-500V.exe: 0xC0000005: Access violation reading location 0x00000000."
It comes when the application calls: InitCVIRTE in this context:
int __stdcall WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
// Initialize LabWindows/CVI run-time library
if (InitCVIRTE (hInstance, 0, 0) == 0)
return -1; /* out of memory */
The debugger indicates that value of hInstance is 0x00400000 {unused=9460301}
Can someone give me a solution to this problem. I have done some search on the Web without success.
Thanks!

I think that exception might be coming from the data execution prevention service that is part of Win XP SP2. The OS thinks that you're somehow trying to execute in the data segment and kills the process. It's intended to catch worms and viruses.
You can turn this service off for non-Microsoft programs using the control panel.
Many pointer handling errors now report as this exception instead of as a memory violation exception. That looks like a null pointer derefence to me.
Menchar
Message Edited by menchar on 11-09-2007 07:12 PM

0xc0000005 access violation running app from mapped drive but no problem from UNC or local

I have an application (.exe - 32 bit) that is giving the access violation error when run from a mapped (net use) drive on a shared folder.   NO error if I run it using the FULL UNC path name and NO error if I copy it to my local drive and run it.
The error is below.   I have run scans for virus and malware, etc. and come up with nothing. I have run diagnostics on my memory and nothing is wrong with the hardware. Also, if I create a new user profile, the app will run fine under
that profile - initially.   The problem seems to come up after I install something new.  I know the new software is not infected (VS 2013) and the software installed before the new profile test was not the same software.
I didn't give all the info below because it's legacy software few would know about and I do NOT have the source code.   It is 32 bit and has worked fine for 15 years or more - without this problem.    Thanks in advance for any help
you can provide.
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x7501e4e4
Faulting process id: 0x31d8
Faulting application start time: 0x01d07f8a4598879e

Hi Johnny，
We wonder if you get this error on all PCs or only on your Windows 7 PCs.
If your application happens to hit a page of memory that is not present, a standard page fault will trigger, telling Windows it needs to fill that page. If the network happens to be down at that moment, Windows will be unable to satisfy the page-fault. So
Windows throws an EXCEPTION_IN_PAGE_ERROR (0xC0000005). Since you mentioned that it works under new user profile initially and already tested your memory, the most typical causes for the ‘0xC0000005: Access Violation’ error are: corrupt registry, malware,
updated software/device driver.
Check your issue with malware, VS 2013 and firewall closed under new account.
If this issue happened recently, you could simply restore your system to earlier point then check your issue.
Check your issue under clean boot and safe mode with network (using new account)
https://support.microsoft.com/en-us/kb/929135
Regards,
D. Wu
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]

Adobe Reader 10.1.7 crashing with memory access violation

After upgrading to 10.1.7 on some Windows Server 2003 SP2 (32-bit) terminal servers, we get Adobe Reader X unable to open any PDF. It launches for a brief second and then closes, apparently with exit code -1073741819 which I was able to get from running Sysinternal Process Monitor, since the Reader application and Windows give no indication or popup error about why the program crashed. I understand this exit code translates to 0xC0000005 "access violation". To make things more interesting, it seems to ONLY occur when accessing the servers via RDP, and may have somethig to do with the configured screen resolution or color depth for that RDP session. In some cases we are able to get Adobe to open for the same user opening the same PDF file without crashing by temporarily changing the RDP settings to a lower resolution, or a color depth other than 256 colors. I tried to disable protected mode at startup via local Group Policy in the registry, but that did not seem to help. We are running McAfee VirusScan Enterprise as well, though I have no indication that is a factor at this point. Any clues on what might be going on here or how to zero in closer on the problem?

From event log, when trying to access preferences.
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 16-05-2012
Time: 14:35:09
User: N/A
Computer: AOCITRIX09
Description:
Faulting application AcroRd32.exe, version 10.1.3.23, faulting module unknown, version 0.0.0.0, fault address 0x000528ef.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 41 63 72   ure Acr
0018: 6f 52 64 33 32 2e 65 78   oRd32.ex
0020: 65 20 31 30 2e 31 2e 33   e 10.1.3
0028: 2e 32 33 20 69 6e 20 75   .23 in u
0030: 6e 6b 6e 6f 77 6e 20 30   nknown 0
0038: 2e 30 2e 30 2e 30 20 61   .0.0.0 a
0040: 74 20 6f 66 66 73 65 74   t offset
0048: 20 30 30 30 35 32 38 65    000528e
0050: 66                        f

Access Violation in DllMain of coherence.dll

I have an issue with C++ project, that using coherence (version 3.7). During loading the exe file dialog box is shown with the message: "The application failed to initialize properly (0xc0000005)". After clicking "OK" the process terminates.
Running under debugger I discovered the error place:
The error: 0xC0000005: Access violation writing location 0x00000010.
The call stack:
 ntdll.dll!_RtlpWaitForCriticalSection@4() + 0x5b bytes
 ntdll.dll!_RtlEnterCriticalSection@4() + 0x46 bytes
 iphlpapi.dll!76d626fd()
 [Frames below may be incorrect and/or missing, no symbols loaded for iphlpapi.dll]
 iphlpapi.dll!76d6605b()
 dnsapi.dll!_IpHelp_GetAdaptersInfo@4() + 0x32 bytes
 dnsapi.dll!_NetInfo_Build@4() + 0x2c bytes
 dnsapi.dll!_NetInfo_Get@8() + 0x28 bytes
 dnsapi.dll!_GetDnsServerRRSet@8() + 0x36 bytes
 dnsapi.dll!_DnsQuery_W@24() + 0xa8 bytes
 mswsock.dll!_myhostent_W@0() + 0xf8 bytes
 mswsock.dll!_RNRPROV_NSPStartup@8() + 0x47 bytes
 mswsock.dll!_NSPStartup@8() + 0x20dc bytes
 ws2_32.dll!NSPROVIDER::Initialize() + 0xa7 bytes
 ws2_32.dll!NSCATALOG::LoadProvider() + 0x4a bytes
 ws2_32.dll!LookupBeginEnumerationProc() + 0x154e bytes
 ws2_32.dll!DCATALOG::EnumerateCatalogItems() + 0x25 bytes
 ws2_32.dll!NSQUERY::LookupServiceBegin() + 0x98 bytes
 ws2_32.dll!_WSALookupServiceBeginW@12() + 0x84 bytes
 ws2_32.dll!_WSALookupServiceBeginA@12() + 0x6f bytes
 ws2_32.dll!getxyDataEnt() + 0x5d bytes
 ws2_32.dll!_gethostname@8() + 0xa7 bytes
 coherence.dll!coherence::native::NativeInetHelper::getLocalHostName() Line 250 + 0x43 bytes C++
 coherence.dll!coherence::net::InetAddress::getLocalHost() Line 84 + 0x10 bytes C++
 coherence.dll!coherence::util::`anonymous namespace'::InetAddressInfo::InetAddressInfo() Line 56 + 0xd bytes C++
 coherence.dll!coherence::lang::factory<coherence::util::`anonymous namespace'::InetAddressInfo>::create() Line 389 + 0x44 bytes C++
 coherence.dll!coherence::lang::class_spec<coherence::util::`anonymous namespace'::InetAddressInfo,coherence::lang::extends<coherence::lang::Object,void>,coherence::lang::implements<void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void> >::create() Line 143 + 0x12 bytes C++
 coherence.dll!coherence::util::`anonymous namespace'::getInetAddressInfo() Line 252 + 0x2a bytes C++
 coherence.dll!coherence::util::`anonymous namespace'::`dynamic initializer for 'coh_static_init_func255''() Line 255 + 0xf bytes C++
 msvcr80.dll!78131742()
 coherence.dll!_CRT_INIT(void * hDllHandle=0x00440000, unsigned long dwReason=0, void * lpreserved=0x0012fd30) Line 316 + 0xf bytes C
 coherence.dll!__DllMainCRTStartup(void * hDllHandle=0x00440000, unsigned long dwReason=0, void * lpreserved=0x00000000) Line 492 + 0x8 bytes C
 coherence.dll!_DllMainCRTStartup(void * hDllHandle=0x00440000, unsigned long dwReason=1, void * lpreserved=0x0012fd30) Line 462 + 0x11 bytes C
 ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes
 ntdll.dll!_LdrpRunInitializeRoutines@4() + 0x205 bytes
 ntdll.dll!_LdrpInitializeProcess@20() - 0x96d bytes
 ntdll.dll!__LdrpInitialize@12() + 0x6269 bytes
 ntdll.dll!_KiUserApcDispatcher@20() + 0x7 bytes
According to [http://msdn.microsoft.com/en-us/library/ms682583(v=vs.85).aspx] :
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called, calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed. Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs. For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS. Unfortunately, there is not a comprehensive list of safe functions in Kernel32.dll.
Windows 2000: Do not create a named synchronization object in DllMain because the system will then load an additional DLL.
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
Perhaps the coherence developers should define init/cleanup functions (i.e. coherence_init(), coherence_cleanup()) and perform all initialization/cleanup actions there.

The test with many dll's does not reproduced this issue. I don't have much time to continue playing with it. BTW look at the simple test application log (the source of the test you can find on my another thread: {thread:id=2286271}) You can see how many times called LoadLibrary() from coherence.dll!DllMain (marked in red). And it doesn't matter, that it works most of the time. It is so called undefined behavior.
Started "TEST.EXE" (process 0x1694) at address 0x00400000 by thread 1. Successfully hooked module.
Loaded "NTDLL.DLL" at address 0x7C900000 by thread 1. Successfully hooked module.
Loaded "KERNEL32.DLL" at address 0x7C800000 by thread 1. Successfully hooked module.
DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" called by thread 1.
DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called by thread 1.
DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1) by thread 1.
Injected "DEPENDS.DLL" at address 0x08370000 by thread 1.
DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called by thread 1.
DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1) by thread 1.
Loaded "COHERENCE.DLL" at address 0x10000000 by thread 1. Successfully hooked module.
Loaded "WS2_32.DLL" at address 0x71AB0000 by thread 1. Successfully hooked module.
Loaded "ADVAPI32.DLL" at address 0x77DD0000 by thread 1. Successfully hooked module.
Loaded "RPCRT4.DLL" at address 0x77E70000 by thread 1. Successfully hooked module.
Loaded "SECUR32.DLL" at address 0x77FE0000 by thread 1. Successfully hooked module.
Loaded "MSVCRT.DLL" at address 0x77C10000 by thread 1. Successfully hooked module.
Loaded "WS2HELP.DLL" at address 0x71AA0000 by thread 1. Successfully hooked module.
Loaded "MSVCP80.DLL" at address 0x7C420000 by thread 1. Successfully hooked module.
Loaded "MSVCR80.DLL" at address 0x78130000 by thread 1. Successfully hooked module.
Loaded "IMAGEHLP.DLL" at address 0x76C90000 by thread 1. Successfully hooked module.
DllMain(0x77FE0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "SECUR32.DLL" called by thread 1.
DllMain(0x77FE0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "SECUR32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77E70000, DLL_PROCESS_ATTACH, 0x0012FD30) in "RPCRT4.DLL" called by thread 1.
DllMain(0x77E70000, DLL_PROCESS_ATTACH, 0x0012FD30) in "RPCRT4.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77DD0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "ADVAPI32.DLL" called by thread 1.
DllMain(0x77DD0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "ADVAPI32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77C10000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCRT.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "InitializeCriticalSectionAndSpinCount") called from "MSVCRT.DLL" at address 0x77C379C2 and returned 0x7C80B8C9 by thread 1.
DllMain(0x77C10000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCRT.DLL" returned 1 (0x1) by thread 1.
DllMain(0x71AA0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "WS2HELP.DLL" called by thread 1.
DllMain(0x71AA0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "WS2HELP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x71AB0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "WS2_32.DLL" called by thread 1.
DllMain(0x71AB0000, DLL_PROCESS_ATTACH, 0x0012FD30) in "WS2_32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x78130000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCR80.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "MSVCR80.DLL" at address 0x78133001 and returned NULL by thread 1. Error: The specified procedure could not be found (127).
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "GetSystemWindowsDirectoryW") called from "MSVCR80.DLL" at address 0x78131F1A and returned 0x7C80ADC9 by thread 1.
DllMain(0x78130000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCR80.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C420000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCP80.DLL" called by thread 1.
DllMain(0x7C420000, DLL_PROCESS_ATTACH, 0x0012FD30) in "MSVCP80.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76C90000, DLL_PROCESS_ATTACH, 0x0012FD30) in "IMAGEHLP.DLL" called by thread 1.
DllMain(0x76C90000, DLL_PROCESS_ATTACH, 0x0012FD30) in "IMAGEHLP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x0012FD30) in "COHERENCE.DLL" called by thread 1.
GetProcAddress(0x71AB0000 [WS2_32.DLL], "accept") called from "WS2_32.DLL" at address 0x71AB737E and returned 0x71AC1040 by thread 1.
[snip]
GetProcAddress(0x71AB0000 [WS2_32.DLL], "freeaddrinfo") called from "WS2_32.DLL" at address 0x71AB737E and returned 0x71AB2B0B by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") called from "WS2_32.DLL" at address 0x71AB4EA0 by thread 1.
Loaded "MSWSOCK.DLL" at address 0x71A50000 by thread 1. Successfully hooked module.
DllMain(0x71A50000, DLL_PROCESS_ATTACH, 0x00000000) in "MSWSOCK.DLL" called by thread 1.
DllMain(0x71A50000, DLL_PROCESS_ATTACH, 0x00000000) in "MSWSOCK.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") returned 0x71A50000 by thread 1.
GetProcAddress(0x71A50000 [MSWSOCK.DLL], "NSPStartup") called from "WS2_32.DLL" at address 0x71AB4EB7 and returned 0x71A5A830 by thread 1.
LoadLibraryA("DNSAPI.dll") called from "MSWSOCK.DLL" at address 0x71A5C714 by thread 1.
Loaded "DNSAPI.DLL" at address 0x76F20000 by thread 1. Successfully hooked module.
DllMain(0x76F20000, DLL_PROCESS_ATTACH, 0x00000000) in "DNSAPI.DLL" called by thread 1.
DllMain(0x76F20000, DLL_PROCESS_ATTACH, 0x00000000) in "DNSAPI.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("DNSAPI.dll") returned 0x76F20000 by thread 1.
GetProcAddress(0x76F20000 [DNSAPI.DLL], "DnsQueryConfigAllocEx") called from "MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F27A55 by thread 1.
LoadLibraryW("rpcrt4.dll") called from "RPCRT4.DLL" at address 0x77E8B42D by thread 1.
LoadLibraryW("rpcrt4.dll") returned 0x77E70000 by thread 1.
GetProcAddress(0x76F20000 [DNSAPI.DLL], "DnsApiFree") called from "MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F237A1 by thread 1.
GetProcAddress(0x76F20000 [DNSAPI.DLL], "DnsQuery_W") called from "MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F22DA3 by thread 1.
LoadLibraryA("iphlpapi.dll") called from "DNSAPI.DLL" at address 0x76F2AB0A by thread 1.
Loaded "IPHLPAPI.DLL" at address 0x76D60000 by thread 1. Successfully hooked module.
Loaded "USER32.DLL" at address 0x7E410000 by thread 1. Successfully hooked module.
Loaded "GDI32.DLL" at address 0x77F10000 by thread 1. Successfully hooked module.
DllMain(0x77F10000, DLL_PROCESS_ATTACH, 0x00000000) in "GDI32.DLL" called by thread 1.
DllMain(0x77F10000, DLL_PROCESS_ATTACH, 0x00000000) in "GDI32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7E410000, DLL_PROCESS_ATTACH, 0x00000000) in "USER32.DLL" called by thread 1.
DllMain(0x7E410000, DLL_PROCESS_ATTACH, 0x00000000) in "USER32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76D60000, DLL_PROCESS_ATTACH, 0x00000000) in "IPHLPAPI.DLL" called by thread 1.
DllMain(0x76D60000, DLL_PROCESS_ATTACH, 0x00000000) in "IPHLPAPI.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("iphlpapi.dll") returned 0x76D60000 by thread 1.
GetProcAddress(0x76D60000 [IPHLPAPI.DLL], "GetAdaptersInfo") called from "DNSAPI.DLL" at address 0x76F2AB5F and returned 0x76D66051 by thread 1.
GetProcAddress(0x76D60000 [IPHLPAPI.DLL], "GetPerAdapterInfo") called from "DNSAPI.DLL" at address 0x76F2AB5F and returned 0x76D66769 by thread 1.
GetProcAddress(0x76F20000 [DNSAPI.DLL], "DnsRecordListFree") called from "MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F25B12 by thread 1.
LoadLibraryA("C:\WINNT\System32\winrnr.dll") called from "WS2_32.DLL" at address 0x71AB4EA0 by thread 1.
Loaded "WINRNR.DLL" at address 0x76FB0000 by thread 1. Successfully hooked module.
Loaded "WLDAP32.DLL" at address 0x76F60000 by thread 1. Successfully hooked module.
DllMain(0x76F60000, DLL_PROCESS_ATTACH, 0x00000000) in "WLDAP32.DLL" called by thread 1.
DllMain(0x76F60000, DLL_PROCESS_ATTACH, 0x00000000) in "WLDAP32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_ATTACH, 0x00000000) in "WINRNR.DLL" called by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_ATTACH, 0x00000000) in "WINRNR.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("C:\WINNT\System32\winrnr.dll") returned 0x76FB0000 by thread 1.
GetProcAddress(0x76FB0000 [WINRNR.DLL], "NSPStartup") called from "WS2_32.DLL" at address 0x71AB4EB7 and returned 0x76FB1688 by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") called from "WS2_32.DLL" at address 0x71AB4EA0 by thread 1.
LoadLibraryA("C:\WINNT\System32\mswsock.dll") returned 0x71A50000 by thread 1.
GetProcAddress(0x71A50000 [MSWSOCK.DLL], "NSPStartup") called from "WS2_32.DLL" at address 0x71AB4EB7 and returned 0x71A5A830 by thread 1.
LoadLibraryA("C:\WINNT\system32\ws2_32") called from "COHERENCE.DLL" at address 0x100A70B4 by thread 1.
LoadLibraryA("C:\WINNT\system32\ws2_32") returned 0x71AB0000 by thread 1.
GetProcAddress(0x71AB0000 [WS2_32.DLL], "getaddrinfo") called from "COHERENCE.DLL" at address 0x100A70C6 and returned 0x71AB2A6F by thread 1.
[snip]
GetProcAddress(0x76F20000 [DNSAPI.DLL], "DnsNameCompare_W") called from "MSWSOCK.DLL" at address 0x71A5C6FD and returned 0x76F2349A by thread 1.
LoadLibraryA("rasadhlp.dll") called from "WS2_32.DLL" at address 0x71AB4FB8 by thread 1.
Loaded "RASADHLP.DLL" at address 0x76FC0000 by thread 1. Successfully hooked module.
DllMain(0x76FC0000, DLL_PROCESS_ATTACH, 0x00000000) in "RASADHLP.DLL" called by thread 1.
DllMain(0x76FC0000, DLL_PROCESS_ATTACH, 0x00000000) in "RASADHLP.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("rasadhlp.dll") returned 0x76FC0000 by thread 1.
GetProcAddress(0x76FC0000 [RASADHLP.DLL], "WSAttemptAutodialAddr") called from "WS2_32.DLL" at address 0x71AB4FCF and returned 0x76FC1AF3 by thread 1.
[snip]
GetProcAddress(0x76FC0000 [RASADHLP.DLL], "WSNoteSuccessfulHostentLookup") called from "WS2_32.DLL" at address 0x71AB4FF3 and returned 0x76FC13A0 by thread 1.
LoadLibraryA("kernel32.dll") called from "COHERENCE.DLL" at address 0x100AC4E3 by thread 1.
LoadLibraryA("kernel32.dll") returned 0x7C800000 by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "RtlCaptureContext") called from "COHERENCE.DLL" at address 0x100AC4F8 and returned 0x7C90331A by thread 1.
LoadLibraryA("C:\WINNT\system32\DBGHELP.dll") called from "IMAGEHLP.DLL" at address 0x76C97327 by thread 1.
Loaded "DBGHELP.DLL" at address 0x59A60000 by thread 1. Successfully hooked module.
Loaded "VERSION.DLL" at address 0x77C00000 by thread 1. Successfully hooked module.
DllMain(0x77C00000, DLL_PROCESS_ATTACH, 0x00000000) in "VERSION.DLL" called by thread 1.
DllMain(0x77C00000, DLL_PROCESS_ATTACH, 0x00000000) in "VERSION.DLL" returned 1 (0x1) by thread 1.
DllMain(0x59A60000, DLL_PROCESS_ATTACH, 0x00000000) in "DBGHELP.DLL" called by thread 1.
DllMain(0x59A60000, DLL_PROCESS_ATTACH, 0x00000000) in "DBGHELP.DLL" returned 1 (0x1) by thread 1.
LoadLibraryA("C:\WINNT\system32\DBGHELP.dll") returned 0x59A60000 by thread 1.
GetProcAddress(0x59A60000 [DBGHELP.DLL], "SymGetOptions") called from "IMAGEHLP.DLL" at address 0x76C97350 and returned 0x59A7B7AD by thread 1.
[snip]
GetProcAddress(0x7C900000 [NTDLL.DLL], "RtlDestroyQueryDebugBuffer") called from "DBGHELP.DLL" at address 0x59A7E675 and returned 0x7C954BC0 by thread 1.
DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x0012FD30) in "COHERENCE.DLL" returned 1 (0x1) by thread 1.
Loaded "SXWMON32.DLL" at address 0x00CC0000 by thread 1. Successfully hooked module.
Loaded "SHELL32.DLL" at address 0x7C9C0000 by thread 1. Successfully hooked module.
Loaded "SHLWAPI.DLL" at address 0x77F60000 by thread 1. Successfully hooked module.
Loaded "OLE32.DLL" at address 0x774E0000 by thread 1. Successfully hooked module.
DllMain(0x77F60000, DLL_PROCESS_ATTACH, 0x00000000) in "SHLWAPI.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "CreateTimerQueue") called from "SHLWAPI.DLL" at address 0x77F65CF9 and returned 0x7C82BFE6 by thread 1.
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DeleteTimerQueueTimer") called from "SHLWAPI.DLL" at address 0x77F65D35 and returned 0x7C821130 by thread 1.
DllMain(0x77F60000, DLL_PROCESS_ATTACH, 0x00000000) in "SHLWAPI.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C9C0000, DLL_PROCESS_ATTACH, 0x00000000) in "SHELL32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "CreateActCtxW") called from "SHELL32.DLL" at address 0x7C9FAB3E and returned 0x7C8154FC by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "ActivateActCtx") called from "SHELL32.DLL" at address 0x7C9E7639 and returned 0x7C80A6E4 by thread 1.
LoadLibraryW("comctl32.dll") called from "SHELL32.DLL" at address 0x7C9FA774 by thread 1.
Loaded "COMCTL32.DLL" at address 0x773D0000 by thread 1. Successfully hooked module.
DllMain(0x773D0000, DLL_PROCESS_ATTACH, 0x00000000) in "COMCTL32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "GetSystemWindowsDirectoryW") called from "COMCTL32.DLL" at address 0x7745B789 and returned 0x7C80ADC9 by thread 1.
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DeactivateActCtx") called from "COMCTL32.DLL" at address 0x7745B6F4 and returned 0x7C80A715 by thread 1.
DllMain(0x773D0000, DLL_PROCESS_ATTACH, 0x00000000) in "COMCTL32.DLL" returned 1 (0x1) by thread 1.
LoadLibraryW("comctl32.dll") returned 0x773D0000 by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DeactivateActCtx") called from "SHELL32.DLL" at address 0x7C9E76A4 and returned 0x7C80A715 by thread 1.
LoadLibraryW("comctl32.dll") called from "SHELL32.DLL" at address 0x7C9FA8A6 by thread 1.
Loaded "COMCTL32.DLL" at address 0x5D090000 by thread 1. Successfully hooked module.
DllMain(0x5D090000, DLL_PROCESS_ATTACH, 0x00000000) in "COMCTL32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "InitializeCriticalSectionAndSpinCount") called from "COMCTL32.DLL" at address 0x5D095338 and returned 0x7C80B8C9 by thread 1.
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DeactivateActCtx") called from "COMCTL32.DLL" at address 0x5D0FF2BF and returned 0x7C80A715 by thread 1.
DllMain(0x5D090000, DLL_PROCESS_ATTACH, 0x00000000) in "COMCTL32.DLL" returned 1 (0x1) by thread 1.
LoadLibraryW("comctl32.dll") returned 0x5D090000 by thread 1.
GetProcAddress(0x5D090000 [COMCTL32.DLL], "InitCommonControlsEx") called from "SHELL32.DLL" at address 0x7C9FA8B6 and returned 0x5D093619 by thread 1.
DllMain(0x7C9C0000, DLL_PROCESS_ATTACH, 0x00000000) in "SHELL32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x774E0000, DLL_PROCESS_ATTACH, 0x00000000) in "OLE32.DLL" called by thread 1.
DllMain(0x774E0000, DLL_PROCESS_ATTACH, 0x00000000) in "OLE32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x00CC0000, DLL_PROCESS_ATTACH, 0x00000000) in "SXWMON32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "SXWMON32.DLL" at address 0x00CD8086 and returned NULL by thread 1. Error: The specified procedure could not be found (127).
[snip]
GetProcAddress(0x7C900000 [NTDLL.DLL], "ZwQueryVirtualMemory") called from "SXWMON32.DLL" at address 0x00CC1958 and returned 0x7C90D97E by thread 1.
DllMain(0x00CC0000, DLL_PROCESS_ATTACH, 0x00000000) in "SXWMON32.DLL" returned 1 (0x1) by thread 1.
GetProcAddress(0x59A60000 [DBGHELP.DLL], "StackWalk64") called from "IMAGEHLP.DLL" at address 0x76C97350 and returned 0x59A83492 by thread 1.
[snip]
GetProcAddress(0x59A60000 [DBGHELP.DLL], "SymGetModuleInfo64") called from "IMAGEHLP.DLL" at address 0x76C97350 and returned 0x59A7C94E by thread 1.
First chance exception 0xE06D7363 (Microsoft C++ Exception) occurred in "KERNEL32.DLL" at address 0x7C812AFB by thread 1.
First chance exception 0xE06D7363 (Microsoft C++ Exception) occurred in "KERNEL32.DLL" at address 0x7C812AFB by thread 1.
Thread 2 started in "KERNEL32.DLL" at address 0x7C8106F9.
DllMain(0x7C900000, DLL_THREAD_ATTACH, 0x00000000) in "NTDLL.DLL" called by thread 2.
DllMain(0x7C900000, DLL_THREAD_ATTACH, 0x00000000) in "NTDLL.DLL" returned 1 (0x1) by thread 2.
DllMain(0x7C800000, DLL_THREAD_ATTACH, 0x00000000) in "KERNEL32.DLL" called by thread 2.
DllMain(0x7C800000, DLL_THREAD_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1) by thread 2.
DllMain(0x10000000, DLL_THREAD_ATTACH, 0x00000000) in "COHERENCE.DLL" called by thread 2.
DllMain(0x10000000, DLL_THREAD_ATTACH, 0x00000000) in "COHERENCE.DLL" returned 1 (0x1) by thread 2.
DllMain(0x71AB0000, DLL_THREAD_ATTACH, 0x00000000) in "WS2_32.DLL" called by thread 2.
DllMain(0x71AB0000, DLL_THREAD_ATTACH, 0x00000000) in "WS2_32.DLL" returned 1 (0x1) by thread 2.
DllMain(0x77DD0000, DLL_THREAD_ATTACH, 0x00000000) in "ADVAPI32.DLL" called by thread 2.
DllMain(0x77DD0000, DLL_THREAD_ATTACH, 0x00000000) in "ADVAPI32.DLL" returned 2147344385 (0x7FFDE001) by thread 2.
DllMain(0x77E70000, DLL_THREAD_ATTACH, 0x00000000) in "RPCRT4.DLL" called by thread 2.
DllMain(0x77E70000, DLL_THREAD_ATTACH, 0x00000000) in "RPCRT4.DLL" returned 4294967041 (0xFFFFFF01) by thread 2.
DllMain(0x77C10000, DLL_THREAD_ATTACH, 0x00000000) in "MSVCRT.DLL" called by thread 2.
DllMain(0x77C10000, DLL_THREAD_ATTACH, 0x00000000) in "MSVCRT.DLL" returned 1 (0x1) by thread 2.
DllMain(0x78130000, DLL_THREAD_ATTACH, 0x00000000) in "MSVCR80.DLL" called by thread 2.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DecodePointer") called from "MSVCR80.DLL" at address 0x78132C33 and returned 0x7C9132FF by thread 2.
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DecodePointer") called from "MSVCR80.DLL" at address 0x78132D4A and returned 0x7C9132FF by thread 2.
DllMain(0x78130000, DLL_THREAD_ATTACH, 0x00000000) in "MSVCR80.DLL" returned 1 (0x1) by thread 2.
DllMain(0x71A50000, DLL_THREAD_ATTACH, 0x00000000) in "MSWSOCK.DLL" called by thread 2.
DllMain(0x71A50000, DLL_THREAD_ATTACH, 0x00000000) in "MSWSOCK.DLL" returned 1 (0x1) by thread 2.
DllMain(0x76F60000, DLL_THREAD_ATTACH, 0x00000000) in "WLDAP32.DLL" called by thread 2.
DllMain(0x76F60000, DLL_THREAD_ATTACH, 0x00000000) in "WLDAP32.DLL" returned 1 (0x1) by thread 2.
DllMain(0x77C00000, DLL_THREAD_ATTACH, 0x00000000) in "VERSION.DLL" called by thread 2.
DllMain(0x77C00000, DLL_THREAD_ATTACH, 0x00000000) in "VERSION.DLL" returned 1 (0x1) by thread 2.
DllMain(0x00CC0000, DLL_THREAD_ATTACH, 0x00000000) in "SXWMON32.DLL" called by thread 2.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DecodePointer") called from "SXWMON32.DLL" at address 0x00CD7CB0 and returned 0x7C9132FF by thread 2.
[snip]
GetProcAddress(0x7C800000 [KERNEL32.DLL], "DecodePointer") called from "SXWMON32.DLL" at address 0x00CD7D94 and returned 0x7C9132FF by thread 2.
DllMain(0x00CC0000, DLL_THREAD_ATTACH, 0x00000000) in "SXWMON32.DLL" returned 1 (0x1) by thread 2.
DllMain(0x7C9C0000, DLL_THREAD_ATTACH, 0x00000000) in "SHELL32.DLL" called by thread 2.
DllMain(0x7C9C0000, DLL_THREAD_ATTACH, 0x00000000) in "SHELL32.DLL" returned 1 (0x1) by thread 2.
DllMain(0x774E0000, DLL_THREAD_ATTACH, 0x00000000) in "OLE32.DLL" called by thread 2.
DllMain(0x774E0000, DLL_THREAD_ATTACH, 0x00000000) in "OLE32.DLL" returned 1 (0x1) by thread 2.
First chance exception 0xE06D7363 (Microsoft C++ Exception) occurred in "KERNEL32.DLL" at address 0x7C812AFB by thread 1.
DllMain(0x5D090000, DLL_PROCESS_DETACH, 0x00000001) in "COMCTL32.DLL" called by thread 1.
Thread 2 exited with code 0 (0x0).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "ReleaseActCtx") called from "COMCTL32.DLL" at address 0x5D0FF202 and returned 0x7C8130FF by thread 1.
DllMain(0x5D090000, DLL_PROCESS_DETACH, 0x00000001) in "COMCTL32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x773D0000, DLL_PROCESS_DETACH, 0x00000001) in "COMCTL32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "ReleaseActCtx") called from "COMCTL32.DLL" at address 0x7745B656 and returned 0x7C8130FF by thread 1.
DllMain(0x773D0000, DLL_PROCESS_DETACH, 0x00000001) in "COMCTL32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x00CC0000, DLL_PROCESS_DETACH, 0x00000001) in "SXWMON32.DLL" called by thread 1.
DllMain(0x00CC0000, DLL_PROCESS_DETACH, 0x00000001) in "SXWMON32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x774E0000, DLL_PROCESS_DETACH, 0x00000001) in "OLE32.DLL" called by thread 1.
DllMain(0x774E0000, DLL_PROCESS_DETACH, 0x00000001) in "OLE32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C9C0000, DLL_PROCESS_DETACH, 0x00000001) in "SHELL32.DLL" called by thread 1.
GetProcAddress(0x7C800000 [KERNEL32.DLL], "ReleaseActCtx") called from "SHELL32.DLL" at address 0x7C9FDF7B and returned 0x7C8130FF by thread 1.
DllMain(0x7C9C0000, DLL_PROCESS_DETACH, 0x00000001) in "SHELL32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77F60000, DLL_PROCESS_DETACH, 0x00000001) in "SHLWAPI.DLL" called by thread 1.
DllMain(0x77F60000, DLL_PROCESS_DETACH, 0x00000001) in "SHLWAPI.DLL" returned 1 (0x1) by thread 1.
DllMain(0x59A60000, DLL_PROCESS_DETACH, 0x00000001) in "DBGHELP.DLL" called by thread 1.
DllMain(0x59A60000, DLL_PROCESS_DETACH, 0x00000001) in "DBGHELP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77C00000, DLL_PROCESS_DETACH, 0x00000001) in "VERSION.DLL" called by thread 1.
DllMain(0x77C00000, DLL_PROCESS_DETACH, 0x00000001) in "VERSION.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76FC0000, DLL_PROCESS_DETACH, 0x00000001) in "RASADHLP.DLL" called by thread 1.
DllMain(0x76FC0000, DLL_PROCESS_DETACH, 0x00000001) in "RASADHLP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_DETACH, 0x00000001) in "WINRNR.DLL" called by thread 1.
DllMain(0x76FB0000, DLL_PROCESS_DETACH, 0x00000001) in "WINRNR.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76F60000, DLL_PROCESS_DETACH, 0x00000001) in "WLDAP32.DLL" called by thread 1.
DllMain(0x76F60000, DLL_PROCESS_DETACH, 0x00000001) in "WLDAP32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76D60000, DLL_PROCESS_DETACH, 0x00000001) in "IPHLPAPI.DLL" called by thread 1.
DllMain(0x76D60000, DLL_PROCESS_DETACH, 0x00000001) in "IPHLPAPI.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7E410000, DLL_PROCESS_DETACH, 0x00000001) in "USER32.DLL" called by thread 1.
DllMain(0x7E410000, DLL_PROCESS_DETACH, 0x00000001) in "USER32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77F10000, DLL_PROCESS_DETACH, 0x00000001) in "GDI32.DLL" called by thread 1.
DllMain(0x77F10000, DLL_PROCESS_DETACH, 0x00000001) in "GDI32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76F20000, DLL_PROCESS_DETACH, 0x00000001) in "DNSAPI.DLL" called by thread 1.
DllMain(0x76F20000, DLL_PROCESS_DETACH, 0x00000001) in "DNSAPI.DLL" returned 1 (0x1) by thread 1.
DllMain(0x71A50000, DLL_PROCESS_DETACH, 0x00000001) in "MSWSOCK.DLL" called by thread 1.
DllMain(0x71A50000, DLL_PROCESS_DETACH, 0x00000001) in "MSWSOCK.DLL" returned 1 (0x1) by thread 1.
DllMain(0x10000000, DLL_PROCESS_DETACH, 0x00000001) in "COHERENCE.DLL" called by thread 1.
DllMain(0x10000000, DLL_PROCESS_DETACH, 0x00000001) in "COHERENCE.DLL" returned 1 (0x1) by thread 1.
DllMain(0x76C90000, DLL_PROCESS_DETACH, 0x00000001) in "IMAGEHLP.DLL" called by thread 1.
DllMain(0x76C90000, DLL_PROCESS_DETACH, 0x00000001) in "IMAGEHLP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C420000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCP80.DLL" called by thread 1.
DllMain(0x7C420000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCP80.DLL" returned 1 (0x1) by thread 1.
DllMain(0x78130000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCR80.DLL" called by thread 1.
DllMain(0x78130000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCR80.DLL" returned 1 (0x1) by thread 1.
DllMain(0x71AB0000, DLL_PROCESS_DETACH, 0x00000001) in "WS2_32.DLL" called by thread 1.
DllMain(0x71AB0000, DLL_PROCESS_DETACH, 0x00000001) in "WS2_32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x71AA0000, DLL_PROCESS_DETACH, 0x00000001) in "WS2HELP.DLL" called by thread 1.
DllMain(0x71AA0000, DLL_PROCESS_DETACH, 0x00000001) in "WS2HELP.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77C10000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCRT.DLL" called by thread 1.
DllMain(0x77C10000, DLL_PROCESS_DETACH, 0x00000001) in "MSVCRT.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77DD0000, DLL_PROCESS_DETACH, 0x00000001) in "ADVAPI32.DLL" called by thread 1.
DllMain(0x77DD0000, DLL_PROCESS_DETACH, 0x00000001) in "ADVAPI32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77E70000, DLL_PROCESS_DETACH, 0x00000001) in "RPCRT4.DLL" called by thread 1.
DllMain(0x77E70000, DLL_PROCESS_DETACH, 0x00000001) in "RPCRT4.DLL" returned 1 (0x1) by thread 1.
DllMain(0x77FE0000, DLL_PROCESS_DETACH, 0x00000001) in "SECUR32.DLL" called by thread 1.
DllMain(0x77FE0000, DLL_PROCESS_DETACH, 0x00000001) in "SECUR32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x08370000, DLL_PROCESS_DETACH, 0x00000001) in "DEPENDS.DLL" called by thread 1.
DllMain(0x08370000, DLL_PROCESS_DETACH, 0x00000001) in "DEPENDS.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C800000, DLL_PROCESS_DETACH, 0x00000001) in "KERNEL32.DLL" called by thread 1.
DllMain(0x7C800000, DLL_PROCESS_DETACH, 0x00000001) in "KERNEL32.DLL" returned 1 (0x1) by thread 1.
DllMain(0x7C900000, DLL_PROCESS_DETACH, 0x00000001) in "NTDLL.DLL" called by thread 1.
DllMain(0x7C900000, DLL_PROCESS_DETACH, 0x00000001) in "NTDLL.DLL" returned 1 (0x1) by thread 1.
Exited "TEST.EXE" (process 0x1694) with code 0 (0x0) by thread 1.
-----

CR XI Unhandled exception in crw32.exe Access violation switching printers

I'm running Crystal Reports Developer 11.0.0.2495. On any report, when I go to page setup and attempt to change the printer to my Dymo 400 Turbo label writer, I get an "unhandled win32 exception occured in crw32.exe [8420]" error. When I go into the debugger it tells me :
Unhandled exception at 0x6a901e35 in crw32.exe: 0xC0000005: Access violation writing location 0x42747570.
I have made an exception in the DEP. Any ideas?

Are you using dual monitor?
Regards,
Shweta

Access violation - access list by code

I have the following code in a windows form application to access a SharePoint list. I have full access to the site collection and the list. However, I got "-1073741819 (0xc0000005) 'Access violation' error when the code tried to access the list. I
have tried it with different list and got the same result.
using (SPSite oSPsite = new SPSite("http://localhost/"))
using (SPWeb oSPWeb = oSPsite.OpenWeb())
SPList aList = oSPWeb.GetList("BTU");
Please advise if you know what is my problem. Many thanks.

GetList expects stringURL and you are passing list title. try oSPWeb.Lists.TryGetList("BTU") if it solves the issue and mark it as answer.

Access violation at 0x6d801017 in java.exe

History, so you can guess why it bothers me at all:
When debugging the C++ part of my JNI application occasionally an error
First-chance exception at 0x6d801017 in javaw.exe: 0xC0000005: Access violation writing location 0x003e0d00.
pops up in Visual Studio.
There's no usable call stack, and it happens occasionally only. Ignoring does not seem to hurt anything.
By reducing everything suspicious and trying to find the trigger for this access violation, I noticed it does not have anything to do with my native code. I don't need to reference any native method or even load my library at all.
But it seems to be related to Garbage Collection.
My test now looks like this:
public class TestGCException {
 public static void main(String[] args) {
 TestGCOnly();
 final static Runtime rt=Runtime.getRuntime();
 static String runFinalize() {
 // can be embedded in code or in Expressions window to be run at every debug step
 rt.runFinalization();
 rt.gc();
 return "Finalized at " + (new java.util.Date(System.currentTimeMillis()));
 public static void TestGCOnly() {
 //java.util.Properties sysProps = System.getProperties();
 //sysProps.list(System.out);
 try {
 System.out.print("Press <Enter> after Attach to process javaw.exe :");
 System.in.read();
 } catch(java.io.IOException iox){};
 System.out.println("Starting Test");
 try {
 int loops = 5;
 while (loops-- > 0) {
 for (int i = 0; i < 100; i++) {
 Long l = new Long(123456789);
 Long l2 = -l;
 l = l2 * 2; // just to avoid "never read" warnings in Eclipse
 Thread.sleep(3);
 runFinalize();
 runFinalize();
 System.out.print(".");
 } catch (InterruptedException e) {
 System.out.print("!");
 System.out.println(" Done");
} It runs fine, but Visual Studio 2008, when attached, reports about 20 such access violations in those 500 loops.
If interesting, here are some of the System Properties:
os.name=Windows XP
os.arch=x86
java.vm.name=Java HotSpot(TM) Client VM
java.vm.version=14.0-b16
java.runtime.version=1.6.0_14-b08
java.vendor=Sun Microsystems Inc. (: that's why I post here :)Usually I run it in Eclipse Ganymede, but that behavior also shows up when run from a command prompt like
 java -cp . TestGCException
Is there more to say than "Ignore that message, and try to avoid (debugging) native code " ?
Edited by: DataFiddler on Sep 25, 2009 8:45 AM

I have the same problem. I tried several versions of the JVM: update 1, 7, 16 and 17.
Access violations are raised at what seems to be random times. I tried your repro above and can confirm access violations are raised.
Because the JVM handles (and swallows) these errors, I can't debug DLL components accessed through JNI in an optimal manner, since this disturbs the VC++ debugger. If my code does an access violation, the debugger won't tell me where - the application just stops, and the debugging session ends.
Worse, we want to trap all system exceptions in our application in order to make sure we close database connexions properly and release locks, but we can't, as we cannot detect whether an access violation is expected (JVM) or not (our code).

CADAPTERSHARED.DLL Access Violation

I am getting strange error code -17502 in Teststand when returning from CVI function to Teststand. CVI function uses C++ dll and works fine until it returns to Teststand. I debugged the code in C++ and got these lines in debug window:
First-chance exception in SeqEdit.exe (CADAPTERSHARED.DLL): 0xC0000005: Access Violation.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
First-chance exception in SeqEdit.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
The thread 0xA00 has exited with code 0 (0x0).
It seems that the error comes from CADAPTERSHARED.DLL. Does anyone know why it happens? I checked that CADAPTERSHARED.DLL is some Teststand dll.
Kind regards, Jarkko Peltonen

Hi,
This is a known error and there's a KnowledgeBase document available:
http://digital.ni.com/public.nsf/websearch/A92CF6B69941B35D862568D900693DF5?OpenDocument
Hopefully this helps.
Thanks,
Vesa K | National Instruments

Access Violation in NIPALU.DLL

When using Traditional NIDAQ in Visual C++ 6, I get an Access Violation exception whenever I run any NIDAQ code. Even the examples cause them from time to time.
It always occurs in pairs (that is, the same exception gets thrown twice in a row) and seems to happen most inside of Init_DA_Brds and Get_DAQ_Device_Info. I set a breakpoint on those functions and there is no exception, step over them and the access violations appear.
What's causing this and how can I make it stop?
"First-chance exception in --- (NIPALU.DLL): 0xC0000005: Access Violation."

Hello Matt,
I believe that the problem you are experiencing is documented in this Knowledge Base article. The article includes several steps for troubleshooting this issue.
If this does not resolve your issue or you believe your error condition is not covered by the article, please reply with the results of the additional steps.
Thank you,
Kyle Bryson
National Instruments

CIN Code memory access violation

I am new to CINs and am trying something simple but get a memory access violation when the following code segment executes:
typedef struct {
int32 dimSize;
uInt8 Numeric[1];
} TD13;
typedef TD13 **TD13Hdl;
MgErr CINRun(TD13Hdl *configMsgDataIn);
MgErr CINRun( TD13Hdl *configMsgDataIn)
/* Insert code here */
(**configMsgDataIn)->Numeric[0] = 10;
return noErr;
How do I reference the array?

Got the same problem!!!
Can someone please tell me what is wrong with the following code?
typedef struct
    int32 dimSize;
    float64 Numeric[1];
} TD1;
typedef TD1 **TD1Hdl;
MgErr CINRun(TD1Hdl *Array);
MgErr CINRun(TD1Hdl *Array)
    int32 size = (**Array)->dimSize;
    return noErr;
Every single time, when trying to acces the array, Dev Studio generates the following error:
Unhandled exception in
Labview.exe (LVS73.TMP) : 0XC0000005: Access Violation.
Whats the deal ??? The input array is not even empty!
Thanks...
SW used :
- VC++ 5.0
- Labview 7 Express - Student edition
- Windows XP Professional SP2

Crash: "Access violation (0xC0000005)"

Hello,
One of our programs has crashed (crash of LabVIEW Runtime).
The reason was an "Access violation (0xC0000005)" in the LabVIEW Runtime.
Because it was an Error of the LabVIEW Runtime, I can not log the Error. This Error occurs only very seldom > than every 3 weeks.
Attached is the error report and a Screenshot of the Error Window.
So I have no Idea how to locate the error.
1. What can cause this Kind Error?
2. How can I locate the error cause?
3. Can National Instrument isolate the error?
Thanks
Sletrab
Attachments:
Error Window.jpg ‏20 KB
1ba236e7-4073-4e5e-9fe2-517a4eb8d8da.zip ‏40 KB

These types of crashes are very conserning, and difficult to isolate (as you already have discovered). Here's what I've done in the past.
Memory monitoring. Built into Windows 7 and newer is the Performance Monitor. Not sure where it is I always click Start then type Performance Monitor. It lets you log data over time and I usually set it up to log my application (or LabVIEW.exe) and look at different memory. There are all kinds of memory from private, to public, and several variations in between. This it self doesn't fix anything but may help in predicting when it happens. If memory increases at some rate and it always dies around the same value it might help.
If you can predict, and reproduce the issue, try changing the code to see if the issue goes away, or happens faster. For me I made my logging routine run twice as fast. So for all data I log I log it twice. If the issue happens sooner it is likly something in the logging routine.
After that I did a binary approach where I would disable parts of the logging code until the issue when away. Turns out it was a bug in the TDMS logging routine that I could isolate and post to the forums. NI agreed and fixed it in an update, and also had a work around until the update went live.
Another thing I've tried is to upgrade to the latest everything and see if it behaves differently. I would make an image of the harddrive as a backup, then upgrade to the latest LabVIEW and drivers for everything. Then try again. In a few cases things were fixed by upgrading, and the cost of upgrade was less than the weeks it would take for me to track down issues that may or may not be my fault.
EDIT: Oh and giving the crash report to NI is a good place to start. Not sure what they can understand from it.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Access violation (0xC0000005)

Hi
I am getting continuing problem with the crashing and Access violation (0xC0000005) at EIP=0x00962D22.
When the crash happens the vi is gettting corrupt and impossible to open next time, so I need to work of the back up.
I tried to recompile everything, change the type defs, update to LabVIEW 12, open on another PC, same thing. I can work for 10min save the work several times do different things, and at one point LV crashes with that error.
Any ideas what to do? It is really a show stopper for me.
The report dump below.
thanks
#Date: Thu, Jan 03, 2013 3:42:12 PM
#OSName: Windows 7 Enterprise
#OSVers: 6.1
#OSBuild: 7600
#AppName: LabVIEW
#Version: 12.0f3 32-bit
#AppKind: FDS
#AppModDate: 10/05/2012 00:12 GMT
#LabVIEW Base Address: 0x00400000
<DEBUG_OUTPUT>
1/3/2013 3:44:28.199 PM
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash 0x0: Crash caught by NIER
minidump id: 7eb8157a-59f0-40af-acb9-a7b7df11beb2
ExceptionCode: 0xC0000005
</DEBUG_OUTPUT>
0x01AF1179 - LabVIEW <unknown> + 0
0x01AF1688 - LabVIEW <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x771973E7 - ntdll <unknown> + 0
0x77159F15 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***

pawel,
I found your post here very interesting as I was having a VERY similar problem. The only notable difference I could find with my situation is I only seemed to encounter this problem on 64-bit systems, and only when my application was a deployed exe. However, I too was using a number of 3rd party .ocx and .dll utilities. But this stubborn Access Violation error was so sporadic (it might have triggered 5 seconds into execution, or 5 hours) it was near impossible to track exactly WHY it was happening.
Have you tried using the LabVIEW Desktop Trace Execution Toolkit yet? I used it to tap into my deployed executable on the target machine while monitoring all VI calls, memory adjustements, etc from my development machine. Although it wasn't a definitive sure-fire way to a solution, it did help me pin-point a pattern.
For about 80% of my crashes, I noticed the last applicable VI to execute (after filtering out a bunch of typical utility VI calls) was "Wait On ActiveX Event.vi". After a bit of digging, this VI was retired quite some time ago and has been upconverted from version to version since. It was written into a library that has been rock solid for years. Although it seemed to execute fine on my devlopment machine (as source code - not a built exe, 32 bit, 64 bit..whatever) and also functioned on all target 32-bit environments wrapped in an exe, it was actually the culprit to my Access Violation errors.
I know how frustrating it is to narrow something like this down. If you're still having issues and you haven't tried that Toolkit, I would suggest giving it a shot.
Good luck.
-Chris
Sr Software and Automation Engineer
Certified LabVIEW Architect
Kod Integrations, LLC
http://www.kodintegrations.com

Access violation (0xC0000005) at EIP=0x012B60E6 within a dynamically called VI

Hi
I have been seeing Access violation (0xC0000005) at EIP=0x012B60E6 within a dynamically called VI.
The VI is called by reference and is strictly typed.
The VI controls a function generator, a robot and a microcontroller device.
All of the above are synchronised using functional globals.
If I let the code run the FG will operate so I know the top level dynamic VI has defiantly been called and successfully entered, however within that VI as other VI’s are called (there are many) LV crashes with access violation.
The VI's within the top level VI are using HiD communicatiuoins over USB with the peripheral instrumants.
The LV crashes are totally random and sometimes the code will operate until the end and close down successfully.
I can only seem to guarantee smooth operation if I set a breakpoint within the top level VI, then the entire system runs perfectly.
In fact it seems that even if I remove the breakpoint (after the first break) and close the VI the system will continue to run until close.
Has anyone any ideas? I have run out!

Hi MAC1,
I have been looking at your issue and wanted to ask if you are calling the VI's into Teststand, using the LabVIEW adapter?
If this is the case, it may be worth looking at another forum post regarding the issue.
LabVIEW Access Violations- Teststand
I am currently looking into what could have caused this access violation.
If you could provide any further information in regards to the top level VI or if you could post it on here, that would be really useful.
Regards,
Dom C

0xC0000005 Access Violation

Similar Messages

Maybe you are looking for