Re^4: Win32::FileOp issues

First of all, thanks for taking the time to reply.

With that callstack, a WAG says its a shell extension causing problems. The things in the callstack is really beyond my knowledge. IDK what an overlay exactly is.

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.

Your original post code.
.
my $struct = pack "LLLpLLLpLpLppLIppLLpILL", ( 88,.
..snip..
is wrong. I found https://metacpan.org/source/JENDA/Win32-FileOp-0.16.02/FileOp.pm#L1217 but that is different from your pack() struct above. .

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.

Looking through Win32::FileOp, nothing looks 64 bit compatible in it. " $Flags = unpack("L", substr $struct, 52, 4);" that is garbage on Win64.
Right, but I'm using 32bit perl.

Use RT bug tracker, dont send private emails to CPAN/maintainers authors. Its like asking for tech support in random blog posts. I see nothing I can associate with you at rt://Win32::FileOp.

Woops, my mistake. In my defense, I thought that that was the whole point for putting someone's mail in the perldoc.

FileOp never calls CommDlgExtendedError. It is commented out. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms646928%28v=vs.85%29.aspx and https://metacpan.org/source/JENDA/Win32-FileOp-0.16.02/FileOp.pm#L1266. Getting that error code and the bool retval of if ($fun->Call($struct)) { should be your first diagnostic.

indeed, that was the first thing I tried. But on the first call to SaveAsDialog the script runs fine; the bool retval is 1 and CommDlgExtendedError gives 0. On the second run I get nothing, as the script crashes on $fun->Call($struct) and I cannot get any value out of it.

What is your Windows 8 Perl, 32 bit or x64? You didn't mention what the retval of Win32::FileOp::SaveAsDialog/console output is of your sample script in your OP.

I'm using 32bit perl

The retval of SaveAsDialog, the first time, is the correct filename, as expected. The second time, it crashes before I can get anything

Thanks a lot for your efforts

Comment on Re^4: Win32::FileOp issues

Replies are listed 'Best First'.
Re^5: Win32::FileOp issues by bulk88 (Priest) on Mar 21, 2014 at 02:40 UTC
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. You can try Googling it. It scares me if I can't stop the PC/OS from calling home. 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. What do you mean same crash? Same C callstack? With Win32::GUI Tk and Tkx? even if you never call Win32::FileOp? 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)` [download] `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>` [download] 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? 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.	[reply] [d/l] [select]
Re^6: Win32::FileOp issues by davide_c (Acolyte) on Mar 21, 2014 at 10:02 UTC
You can try Googling it. It scares me if I can't stop the PC/OS from calling home. I did a lot of googling, couldn't find anything relevant yet about the GetSyncTransferStatus or similar functions. I did, however, find a way to hide Skydrive through some registry editing (but I'm not sure it disables it completely), which didn't cancel the crashes completely, but i think it made them less frequent What do you mean same crash? Same C callstack? With Win32::GUI Tk and Tkx? even if you never call Win32::FileOp? Yes, same callstack. Or at least it looks like it to me. This is, for example, the callstack after a crash using only Win32::GUI, using a simple script (like in the OP, only with Win32::GUI) from commandline perl. ChildEBP RetAddr Args to Child 05e6f600 75c66079 05e6f634 05e6f638 0584a6b8 SHELL32!GetSyncTransferSt +atus+0x5d 05e6f8c4 75a6e121 00000002 05e6f900 00000000 SHELL32!`anonymous namesp +ace'::_GetItemStatusHelper+0x277 05e6f8e8 75a6e0ce 05e6f994 05e6f900 80004005 SHELL32!CBaseOverlayHandl +er::_GetItemStatus+0x50 05e6f904 75a6b8b0 0584a6b0 05e6f994 00000011 SHELL32!CBaseOverlayHandl +er::IsMemberOf+0x1c 05e6f93c 75bed394 05e6f994 00000011 00000064 SHELL32!CFSIconOverlayMan +ager::_GetFileOverlayInfo+0xa9 05e6f958 75a6e2f6 0069a9f8 05e6f994 00000011 SHELL32!CFSIconOverlayMan +ager::GetFileOverlayInfo+0x20 05e6fba0 75a6e1b2 00000000 05e6fc64 00000001 SHELL32!CFSFolder::_GetOv +erlayInfo+0x12c 05e6fbb4 75caa022 04d03b00 00000000 05e6fc64 SHELL32!CFSFolder::GetOve +rlayIndex+0x21 05e6fc20 75a6ae8f 04c92140 05e6fc64 00000000 SHELL32!`Microsoft::WRL:: +Module<1,Microsoft::WRL::Details::DefaultModule<5> >::Create'::`2'::` +dynamic atexit destructor for 'module''+0x56c5 05e6fc40 605c2b49 058895f0 04c92140 05e6fc64 SHELL32!CRegFolder::GetOv +erlayIndex+0x2d 05e6fc5c 605c2ad3 ffffffff 04c92140 00000000 explorerframe!CNscOverlay +Task::_Extract+0x32 05e6fc78 605b770f 04c91a00 04c92190 00200000 explorerframe!CNscOverlay +Task::InternalResumeRT+0x32 05e6fc94 75a00665 00c91a00 0000ea60 00696a48 explorerframe!CRunnableTa +sk::Run+0xab 05e6fcac 759b8a1b 05e6fcfb 00654798 00696a48 SHELL32!CShellTask::TT_Ru +n+0x2c 05e6fd5c 759b8bc3 020ed3b0 05e6fd78 751f1f86 SHELL32!CShellTaskThread: +:ThreadProc+0x136 05e6fd68 751f1f86 00696a48 04cc1538 05e6fdf4 SHELL32!CShellTaskThread: +:s_ThreadProc+0x2b 05e6fd78 77e40e92 020ed3b0 7970f9f1 00654798 SHCORE!ExecuteWorkItemThr +eadProc+0xe 05e6fdf4 77e3f6c0 020ed3b0 04cc1538 7970fb89 ntdll!RtlpTpWorkCallback+ +0xe6 05e6ff8c 7721495d 00654798 05e6ffdc 77e698ee ntdll!TppWorkerThread+0x4 +87 05e6ff98 77e698ee 00654798 7970fbd9 00000000 KERNEL32!BaseThreadInitTh +unk+0xe 05e6ffdc 77e698c4 ffffffff 77e5e0f0 00000000 ntdll!__RtlUserThreadStar +t+0x20 05e6ffec 00000000 77e35658 00654798 00000000 ntdll!_RtlUserThreadStart ++0x1b [download] And this is using only Tk, within a bigger program called within an executable packaged with perlapp: ChildEBP RetAddr Args to Child 1800f600 75c66079 1800f634 1800f638 0b34a538 SHELL32!GetSyncTransferSt +atus+0x5d 1800f8c4 75a6e121 00000002 1800f900 00000000 SHELL32!`anonymous namesp +ace'::_GetItemStatusHelper+0x277 1800f8e8 75a6e0ce 1800f994 1800f900 80004005 SHELL32!CBaseOverlayHandl +er::_GetItemStatus+0x50 1800f904 75a6b8b0 0b34a530 1800f994 00000011 SHELL32!CBaseOverlayHandl +er::IsMemberOf+0x1c 1800f93c 75bed394 1800f994 00000011 00000064 SHELL32!CFSIconOverlayMan +ager::_GetFileOverlayInfo+0xa9 1800f958 75a6e2f6 002c65c0 1800f994 00000011 SHELL32!CFSIconOverlayMan +ager::GetFileOverlayInfo+0x20 1800fba0 75a6e1b2 00000000 1800fc64 00000001 SHELL32!CFSFolder::_GetOv +erlayInfo+0x12c 1800fbb4 75caa022 0b3847a8 00000000 1800fc64 SHELL32!CFSFolder::GetOve +rlayIndex+0x21 1800fc20 75a6ae8f 08a02538 1800fc64 00000000 SHELL32!`Microsoft::WRL:: +Module<1,Microsoft::WRL::Details::DefaultModule<5> >::Create'::`2'::` +dynamic atexit destructor for 'module''+0x56c5 1800fc40 61c12b49 089bf188 08a02538 1800fc64 SHELL32!CRegFolder::GetOv +erlayIndex+0x2d 1800fc5c 61c12ad3 ffffffff 08a02538 00000000 explorerframe!CNscOverlay +Task::_Extract+0x32 1800fc78 61c0770f 08a05ef0 08a05788 00200000 explorerframe!CNscOverlay +Task::InternalResumeRT+0x32 1800fc94 75a00665 00a05ef0 0000ea60 003128e0 explorerframe!CRunnableTa +sk::Run+0xab 1800fcac 759b8a1b 1800fcfb 00265ed0 003128e0 SHELL32!CShellTask::TT_Ru +n+0x2c 1800fd5c 759b8bc3 0abbf8b0 1800fd78 751f1f86 SHELL32!CShellTaskThread: +:ThreadProc+0x136 1800fd68 751f1f86 003128e0 089dfc88 1800fdf4 SHELL32!CShellTaskThread: +:s_ThreadProc+0x2b 1800fd78 77e40e92 0abbf8b0 e94ddd00 00265ed0 SHCORE!ExecuteWorkItemThr +eadProc+0xe 1800fdf4 77e3f6c0 0abbf8b0 089dfc88 e94ddf78 ntdll!RtlpTpWorkCallback+ +0xe6 1800ff8c 7721495d 00265ed0 1800ffdc 77e698ee ntdll!TppWorkerThread+0x4 +87 1800ff98 77e698ee 00265ed0 e94ddf28 00000000 KERNEL32!BaseThreadInitTh +unk+0xe 1800ffdc 77e698c4 ffffffff 77e5e0e8 00000000 ntdll!__RtlUserThreadStar +t+0x20 1800ffec 00000000 77e35658 00265ed0 00000000 ntdll!_RtlUserThreadStart ++0x1b [download] As for your suggestions, I'll try using Dependency Walker and give you the results, this will take a few days, as I had to give back the pc I borrowed... thanks a lot	[reply] [d/l] [select]
Re^6: Win32::FileOp issues by davide_c (Acolyte) on Jun 06, 2014 at 15:39 UTC
Ok. I know it took a looong time, but.. I finally managed to set up a windows 8.1 virtual machine. Installed perl, script crashes as before. Installed dbg, got same results. Started dependency walker... when i start profiling perl.exe it just hangs (not responding)... I found this problem maybe mentioned here but that 2.6.8288 version doesn't seem to actually exist anywhere.	[reply]