in reply to Re^4: Win32::FileOp issues
in thread Win32::FileOp issues
from the GetSyncTransferStatus part, my guess is that it's part of some cloud storage software, that overlays an indicator to file icons to specify wether they are in sync or not.
The pc I'm testing has actually 3 of them: Google Drive, Dropbox and Skydrive.
I'm suspecting Skydrive is to blame, as disabling the other two didn't change anything. Can't disable skydrive, though, as it's an integral part of windows 8.1.
That was my first test, as at first I thought the script crashed due to changes to the struct in the windows API. That way I could get a simpler windows that crashed less frequently (I now think that possibly that window has a lower chance of displaying folders that are involved in the icon overlay thing). But probably the problem lies, as you said, in something external, as I get the same crash using other modules (Win32::GUI, Tk, and Tkx).
The question, however, is: why does it crash within perl only? After all, those common dialogs are used everywhere.
Perl has a class of problems in Win32 related to threads. A Perl Interp can never execute in 2 OS threads at the same time, and special C functions exported by the perl interp must be called to move the interp between OS threads (which are different from ithreads) (Im simplying it, go read perlguts for TMI). IDK if this is one of your problems. Can you list the C callstacks of all other threads at the moment of the crash please? You are using Windbg, which I hate since I belive only its author finds it easy to use or understand. I prefer Visual Studio IDE C debugger.
Woops, my mistake. In my defense, I thought that that was the whole point for putting someone's mail in the perldoc.
You can use them, as CCs, when you post to a public ML like http://www.nntp.perl.org/group//http://lists.perl.org/. Note lists.perl.org doesn't mention all the groups on the server, for example, libwin32 is missing from lists.perl.org, but works as an valid email ML, and appears on the nntp site.What I think is going on is, a certain DLL is being unloaded at some point from your process. IDK its name. Look at the windbg output in Re^2: Win32::FileOp issues. "75f44bb3 ff501c call dword ptr eax+1Ch ds:002b:6fe06918=????????". 32 bit windows user mode address space ends at 0x7FFFFFFF (there is an exception, TMI, wont mention). Above that is kernel space. MS rebases its DLLs so all the OS DLLs are piled at the end of address space (0x7FFFFFFF) and work their way down (order IDK about, there may be an intelligent order by MS, or it might be random). Register eax contains 0x6fe068fc. I bet that that is the start of a C const static vtable of function pointers that lives in a DLL (this might be a MSVC C++ object or a COM object, they are hard to distinguish on a machine code level). That DLL was mapped at one point in the process to the C++ object. IDK if its a COM object, the offset into the vtable, 0x1c / 4 = 0x7, the most 2 common com objects base classes in the world are IUnknown and IDispatch (inherits from IUnknown), Invoke method is at offset 6 http://msdn.microsoft.com/en-us/library/ms221608.aspx. Even if it was <= 6, no guarentees its COM. But anyway, lets continue. Searching the module list shows
ModLoad: 6fe00000 6fe0f000 C:\WINDOWS\SysWOW64\mssprxy.dll (1584.1b10): Unknown exception - code 8001010e (first chance)
So 0x6fe06918 should absolutely be a valid memory address (now if the memory page is marked executable, and if it has valid machine code at the address are different issues ;)). Can you use a memory watch window and see if 0x6fe06918 has real bytes at it and around it or just "?? ?? ?? ?? etc" around it?C:\Documents and Settings\Owner>perl -E "say 0x6fe06918 > 0x6fe00000" 1 C:\Documents and Settings\Owner>perl -E "say 0x6fe06918 < 0x6fe0f000" 1 C:\Documents and Settings\Owner>
mssprxy.dll doesn't exist in XP, so IDK what it does and I've never heard of it. I suggest you run the crashing perl script/perl process from Dependency Walker http://www.dependencywalker.com/ . Use the profiling feature in DW to start the process. Paste here the log from the bottom of DW. I want to see what is the lifetime of mssprxy.dll being loaded in the process.
IDK what error 0x8001010e/RPC_E_WRONG_THREAD http://support.microsoft.com/kb/172314 http://support.microsoft.com/kb/206076 has to do with the problem. IDK if mssprxy.dll in its DllMain or callees raised a RPC_E_WRONG_THREAD exception and the exception made its way back to the DLL loader without being caught by anything in the middle, and the DLL was therefore unloaded and LoadLibrary returned FALSE. Or if RPC_E_WRONG_THREAD was thrown, but mssprxy.dll intentionally caught the exception and continued execution (a perfectly normal thing sometimes). Dep Walker will show what happened.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^6: Win32::FileOp issues
by davide_c (Novice) on Mar 21, 2014 at 10:02 UTC | |
|
Re^6: Win32::FileOp issues
by davide_c (Novice) on Jun 06, 2014 at 15:39 UTC |