We are finding that deleting folders using SHFileOperation is very slow on systems that have been updated to 1709. It seems like there's something that's crept in related to Universal Windows apps that is causing this.
This code:
sFileOp.wFunc = FO_DELETE;
sFileOp.pFrom = buf;
sFileOp.fFlags = FOF_SILENT|FOF_NOCONFIRMATION|FOF_NOERRORUI;
if(SHFileOperation(&sFileOp))
passed a path like "C:\Jobs\Job1" (yes, doubly null terminated) with a small number of files in the folder -- say 2 or 3 - runs in milliseconds on Windows 7 and Windows 10 1511. On Windows 10 1709 it takes between 1 and 3 seconds.
What we notice in the Visual Studio 2013 Output window are 3 or 4 of these messages after SHFileOperation has been called and before it returns:
onecoreuap\shell\windows.storage\sharedstoragesources\util.cpp(2831)\windows.storage.dll!7650BF24: (caller: 765D88E4) ReturnHr(1) tid(1bb0) 80070490 Element not found.
This is a Win32, x86 app built with VS2013. This occurs on a release we've been shipping for over 18 months. To recap version runs as expected on 1511 and Windows 7, much too slowly on the last two Windows 10 updates. Somehow we've gotten tangled up with the Universal Windows app DLLs, it seems. How do we avoid this?
Related
I am trying to help one of my customer to migrate a very old vc++ program which works on Windows 2003 as a win32 service to x64. It was compiled with VC 2005.
I have migrated to VC 2019 with windows SDK 10 & Windows 10.
There were few minor issues in DB and windows service ATL. I was able to fix them all.
Now there is a strange issue with the IOCP wherein the GetQueuedCompletionStatus results in success but the psobSockInfo and PerIoData results in unable to read error. (attached to the process in vs 2019 in debug mode).
bResult = GetQueuedCompletionStatus(sobIocpThParam->hReqRecThread,&BytesTransferred,(PDWORD_PTR)&psobSockInfo,(LPOVERLAPPED *) &PerIoData,INFINITE);
The code is written very similarly to this example and the header file in line with
I have tried to zero both the memory, tried to set the pointers to NULL. Nothing has helped. The bResult is 1. BytesTransfered is 177, The socket handle is valid.
Can any one point me in the right direction?
I was using RAD 10.1 (Berlin) with no problem until now... Last month I applied Windows Creator Update and was occupied by other businesses... Now, each time I start the IDE, the loading progresses quickly up to "All design time packages loaded". At this time RAD studio sits on its splash window and consumes ~25% CPU. It takes at least 10 minutes before the IDE appears...
I've installed RAD 10.2 (Tokyo) and all provided patches, hoping for a fix... But the problem remains the same.
I can't go back to previous version of Windows 10 (more than 10 days after install).
I've already searched for an answer and Matthias E suggested that it was linked to https://quality.embarcadero.com/browse/RSP-17972.
But, in my case, the (very) long period stands only for IDE loading even when there is no project to (auto)load. I'm not talking about the time-period to load the project or to start project execution or even to start the application execution. Once the IDE has been loaded (after ~20'), everything (editing, compilation, building, debugging, execution) is working quickly...
I have become accustomed to never close the IDE once opened but this is particularly disturbing.
Could you help me ?
--- Edited ---
For those who cannot access the link above, here is the content :
Details
Type: Bug Bug
Status: Open Open
Priority: Major Major
Resolution: Unresolved
Affects Version/s: 10.2 Tokyo, 10.1 Berlin Update 2
Fix Version/s: None
Component/s: Debugger, IDE (Development Environment), Libraries/Frameworks
Labels: None
Platform: Windows 10
Language Version: English
Edition: Professional
InternalID: RS-83785
InternalStatus: Open
Description
The debugger goes haywire for everyone in our organization with Creators and Tokyo/Berlin. Reverting to Windows Anniversary brings back the sanity.
Debugger problems with Tokyo/Berlin and Creators:
App takes a long time to load with modules loading and unloading and re-loading many times
IDE freezes
Memory consumption of bds.exe explodes, sometimes (> 3GB)
I will attached before and after screenshots showing how modules load and unload and re-load with Windows 10 Creators.
I presume these problems have the same root cause(s) than those in https://forums.embarcadero.com/thread.jspa?messageID=884382*
--- ---
Thanks to Lieven Keersmaekers's suggestion to use procmon, I was able to find the cause of the problem. RAD studio was heavily trying to access an enormous (128 GB) zip backup file (see : qed-electronic.com/Download/170808-ProcMonTrace.jpg ). I've simply moved the backup file to another location and RAD studio now starts as before. I have no idea why RAD wanted so much to access this file : none of my project files were located in this zip. The Windows Creator Update was apparently not guilty...
bds.exe must be launch with only one CPU !
CPU Affinity CPU=0
Thx to Javorszky
https://community.embarcadero.com/forum/installation-issues/1408-running-from-ide-freezes-windows-10#4173
To run quickly without entring TaskManager and change Setting CPUAffinity,
just create a batch file on the desktop:
cd "C:\Program Files (x86)\Embarcadero\Studio\19.0\bin\"
start /affinity 1 bds.exe
Why ?
"The reason for this is that most applications you run these days have been designed with multi-core processors in mind and will work with the operating system to distribute their operations as evenly as possible across all the available cores. "
see : https://www.techrepublic.com/blog/windows-and-office/change-the-processor-affinity-setting-in-windows-7-to-gain-a-performance-edge/
I have Visual Studio 2013 Ultimate with Update 4. Computer is Windows 7, 64 bit, 8gb ram, 1tb hd. Multiple times a day it will lock up and crash while I am doing normal coding operations. Sometimes its while i'm opening a file, or renaming a variable, or just typing code. It was doing this with Update 3 and Update 2. Does anyone know how to fix this?
edit 2: I started working in a secondary project for a different portion of program and noticed it only happens when working in my big project (22k lines, 70+ files). The new project im working in is only 10 files and 2k lines of code, and has not crashed for the week i've been in it so far.
edit: here is the xml error log when it crashes
<WERReportMetadata>
<OSVersionInformation>
<WindowsNTVersion>6.1</WindowsNTVersion>
<Build>7601 Service Pack 1</Build>
<Product>(0x1): Windows 7 Ultimate</Product>
<Edition>Ultimate</Edition>
<BuildString>7601.18526.amd64fre.win7sp1_gdr.140706-1506</BuildString>
<Revision>1130</Revision>
<Flavor>Multiprocessor Free</Flavor>
<Architecture>X64</Architecture>
<LCID>1033</LCID>
</OSVersionInformation>
<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>devenv.exe</Parameter0>
<Parameter1>12.0.31101.0</Parameter1>
<Parameter2>54548724</Parameter2>
<Parameter3>Microsoft.VisualStudio.Shell.ViewManager</Parameter3>
<Parameter4>12.0.31101.0</Parameter4>
<Parameter5>545487c9</Parameter5>
<Parameter6>501</Parameter6>
<Parameter7>2f</Parameter7>
<Parameter8>System.ArgumentOutOfRange</Parameter8>
</ProblemSignatures>
<DynamicSignatures>
<Parameter1>6.1.7601.2.1.0.256.1</Parameter1>
<Parameter2>1033</Parameter2>
<Parameter22>0a9e</Parameter22>
<Parameter23>0a9e372d3b4ad19135b953a78882e789</Parameter23>
<Parameter24>0a9e</Parameter24>
<Parameter25>0a9e372d3b4ad19135b953a78882e789</Parameter25>
</DynamicSignatures>
<SystemInformation>
<MID>2AAE6B99-B3F8-41BF-BE92-B48165152E42</MID>
<SystemManufacturer>MSI</SystemManufacturer>
<SystemProductName>MS-7721</SystemProductName>
<BIOSVersion>V30.3</BIOSVersion>
</SystemInformation>
</WERReportMetadata>
I have this weird problem that's killing us. I have a widely used app that is written in VB6.
Everything works fine. This week I decided to chance the computer where we do the compiling. I tried not to tempt our luck, so I had an AMD X2 270 with DDR3 and a Gigabyte motherboard (I though it was better not to go with bigger hardware and W7 so Visual Studio 6 would be easier to install...)
I installed Windows XP SP3, because the main purpose of that computer is perform the vb6 application maintenance, besides common tasks such as email checking, web surfing and web programming with other tools.
PROBLEM IS: executables generated in this new computer are painfully slow!!! My old computer (pentium 4, also XP) creates executables that works just fine.
Both have Visual Studio 6 SP 5.
They work just fine in the computer where it is compiled, but as soon as i move the exe file to a computer that already has the app, it goes nearly impossible to use.
Anybody has any ideas???? We are kind of puzzled here, not to mention worried. (The "old" machine has presented sign of failure recently, like rebooting itself)
More info: the app talks with sql server 2000, uses a flexgrid and Crystal Reports 8.5
Thanks in advance,
Daniel
For whatever it's worth, I have a bunch of old legacy stuff installed on my XP computer, including MSVS 6/Pro. Also, for whatever it's worth, I cannot think of any reason for the same MSVS6 compiler to produce different .exe's on different machines.
SUGGESTIONS:
1) When you get a chance, please post back a command-line "dir" of the "good" .exe vs. the "bad" .exe. Do the file sizes match?
2) Please run "depends" (one of the MSVS6 tools, as you probably know) on the "good" .exe on the "good" PC, vs. the "bad" .exe on the "bad" .exe. Do both .exe's use the same .dll's, from the same places, with the same versions?
3) What about your VBRUN.dll? For example:
Directory of C:\WINDOWS\system32
03/31/2003 05:00 AM 1,355,776 msvbvm50.dll
04/13/2008 05:12 PM 1,384,479 msvbvm60.dll
4) What happens if you copy the "good" .exe from the "good" computer to the bad? Does the "good" .exe suddenly behave "bad"?
5) What do you see in task mgr. Any difference between the "good" PC and "bad" PC in %CPU? Memory/Paging? I/O reads/writes?
Thank you in advance
I get the following error compiling with make (I have cygwin.dll)
*** Couldn't reserve space for cygwin's heap (0x150000) in child, cygheap, Win32 error 0
0 [main] make 4336 sync_with_child: child 2968(0x120) died before initialization with status code 0x1
308 [main] make 4336 sync_with_child: *** child state waiting for longjmp
How could it be solved?
Thanks
I just ran into this problem and was advised to rebase the msys-1.0.dll which was causing the problem.
Specifically, I used the ReBase.exe tool:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64\ReBase.Exe
which is part of v7.1 (and perhaps other versions) of Microsoft's platform sdk available here.
take a backup of the dll, and then try this command line inside the platform sdk command prompt:
rebase -b 0x30000000 /path/to/msys-1.0.dll
this solved the issue for me.
for interest, my recommended virtual memory settings were set at around 3GB, and the actual allocated virtual memory was at 6GB.
Reboot your system:
Most users complaining about this problem reported it goes away after a reboot. If you are using Windows 7, check the message from BerndP in this thread, it has some tips related to adjusting Virtual Memory settings on Windows.
Might be some software interfering with Cygwin:
This post brings an interesting discussion of random problems with Cygwin. The BLODA list presents a list of applications that are known to cause strange failures and problems in Cygwin.
EDIT:
Windows 8 has not been officially released, so don't expect Cygwin to work on it.
Cygwin can be expected to run on all modern 32 bit versions of Windows This includes, as of the time of writing this, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, as well as the WOW64 32 bit environment on released 64 bit versions of Windows (XP/2003/Vista/2008/7/2008 R2).
I am working with eclipse and am using MinGW + Yagarto on Windows 8. Restarting did nothing.
I solved the issue by expanding my virtual memory, which was originally set to 896Mb and is not at 3000Mb and working fine.
This problem can be resolved by changing the compatibility mode of gcc.exe (or whatever called by make) into Windows Xp (in Properties->compatibility)
However, the script must be executed as administrator to avoid multiple confirmations when calling gcc.exe