I am using URLDownloadToFile to download files from internet in VB 6.0.
The issue is that if I restrict my bandwidth of network, my application halts when I start downloading.
I am using callbacks to check the progress of download and timeout, but when my application halts my callback methods even not fire.
I also used VB timer to check the progress of download but this timer also not fired if my application is in halt state.
I want to abort the downloading if the server is not responding, kindly suggest me any solution to solve this.
EDIT
I have resolved this issue using AsyncRead in VB, AsyncRead is natively available in VB and can resolved these kind of issue, Following link may help you.
http://visualstudiomagazine.com/articles/2008/03/27/simple-asynchronous-downloads.aspx
VB 6 does not support multithreading; VB 6 apartment threaded objects and programs are limited to execution in an STA (Single Threaded Apartment). This means that your exe can spin up as many threads as it wants, but only one thread in the apartment can execute at a time (no concurrent execution).
You can create VB.Net wrapper COM visible class and make file download in separate thread.
Related
We are trying to troubleshoot a nasty problem on a production server where the server will start misbehaving after running for awhile.
Diagnostics have led us to believe there may be a bug in a DLL that is used by one of the processes running on this server that is resulting in a global atom leak. The assumed vector is a process that is calling RegisterClass without a corresponding UnregisterClass (and the class name is using a random number as part of the name, so it's a different class name each time the process starts).
This article provided some information: https://blogs.msdn.microsoft.com/ntdebugging/2012/01/31/identifying-global-atom-table-leaks/
But we are reluctant to attempt kernel mode debugging on a production server, so we have tried installing windbg and using the !gatom command to list atoms for a given session.
I use windbg to attach to a process in one of the sessions (these processes are running as Windows Services if that matters), then invoke the !gatom command. The returned atom list doesn't have any window classes in it.
Then I read this: https://blogs.msdn.microsoft.com/oldnewthing/20150429-00/?p=44984
and it sounds like there is a separate atom table for windows classes. And no way to query it. I was hoping that we'd be able to actually see how many windows class atoms have been registered, and see if that list gets bigger over time, indicating a leak.
The documentation on !gatom is sparse, and I'm hoping I can get some expert confirmation or recommendations on how to proceed.
Does anyone have any ideas on how we can get at the list of registered Windows classes on a production server?
More detail about what happens when the server starts to misbehave:
We run many instances (>50) of the same application as separately registered services running from isolated executables and DLLs - so each of those 50 instances has their own private executables and DLLs.
During their normal run, the processes unload and reload a DLL (about every hour). There is a windows class used that's part of a "session handle" used by the DLL (the session handle is part of the registered windows class name), and that session handle is unique each time the DLL is loaded. So every hour, there is an additional Window class registration, made by a DLL (our service stays running).
After some period of time, the system will get into a state where further attempts to load the DLL in question fail. This may happen for one of the services, then gradually over time, other services will start to have the same problem.
When this happens, restarting the service does not fix the problem. The only way that we've found to get things running properly again is to reboot the server.
We are monitoring memory commit load, and we are well within the virtual memory of the server. We are even within the physical memory size.
I just did a code review the vendor of the DLL, and it looks like they are not actually calling RegisterClass from the DLL itself (they only make one RegisterClass call from the DLL, and it's a static string - not a different class name for each session). The DLL launches an EXE, and that EXE is the one that registers the session specific class name. Their EXE does call UnregisterClass (and even if it didn't, the EXE is terminated when we unload their DLL, so it seems that this may not be what is going on).
I am now out of bullets on this one. The behavior seems like some sort of resource leak or pool exhaustion. The next time this happens, I will try connecting to the failing process with windbg and see what the application atom pool looks like - but I'm not hopeful that is going to shed any light.
Update: The excellent AtomTableMonitor tool has narrowed the problem to rogue RegisterWindowMessage. I'm going to ask a more specific question focused on this exact issue: Diagnosing RegisterWindowsMessage leak
You may try using this standalone global atom monitor
The application appears to have capabilities to monitor atoms in services
that run in a different session
btw if you have narrowed it to RegisterWindowMessage
then spy++ can log the Registered messages system wide along with thread and process
spy++ (i am using it from vs2015 community)
ctrl+m select all windows in system
in the messages tab clear all and select registered
and start logging
you can also save the log (it is plain text in-spite of strange extension )
powershell -c "gc spy++.sxl -Tail 3"
<000152> 001F01A4 P message:0xC1B2 [Registered:"nsAppShell:EventID"] wParam:00000000 lParam:06EDFCE0 time:4:2
7:49.584 point:(408, 221)
<000153> 001F01A4 P message:0xC1B2 [Registered:"nsAppShell:EventID"] wParam:00000000 lParam:06EDFCE0 time:4:2
7:49.600 point:(408, 221)
<000154> 001F01A4 P message:0xC1B2 [Registered:"nsAppShell:EventID"] wParam:00000000 lParam:06EDFCE0 time:4:2
7:49.600 point:(408, 221)
I have a completely random error popping up on a particular piece of software out in the field. The application is a game written in VB6 and is running on Windows 7 64-bit. Every once in a while, the app crashes, with a generic "program.exe has stopped responding" message box. This game can run fine for days on end until this message appears, or within a matter of hours. No exception is being thrown.
We run this app in Windows 2000 compatibility mode (this was its original OS), with visual themes disabled, and as an administrator. The app itself is purposely simple in terms of using external components and API calls.
References:
Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library
Components:
Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT
As you can see, these are pretty straightforward, Microsoft-standard tools, for the most part. The database components exist to interact with an Access database used for bookkeeping, and the Resizer XT was inserted to move this game more easily from its original 800x600 resolution to 1920x1080.
There is no networking enabled on the kiosks; no network drivers, and hence no connections to remote databases. Everything is encapsulated in a single box.
In the Windows Application event log, when this happens, there is an Event ID 1000 faulting a seemingly random module -- so far, either ntdll.dll or lpk.dll. In terms of API calls, I don't see any from ntdll.dll. We are using kernel32, user32, and winmm, for various file system and sound functions. I can't reproduce as it is completely random, so I don't even know where to start troubleshooting. Any ideas?
EDIT: A little more info. I've tried several different versions of Dependency Walker, at the suggestion of some other developers, and the latest version shows that I am missing IESHIMS.dll and GRPSVC.dll (these two seems to be well-known bugs in Depends.exe), and that I have missing symbols in COMCTRL32.dll and IEFRAME.dll. Any clues there?
The message from the application event log isn't that useful - what you need is a post mortem process dump from your process - so you can see where in your code things started going wrong.
Every time I've seen one of these problems it generally comes down to a bad API parameter rather than something more exotic, this may be caused by bad data coming in, but usually it's a good ol fashioned bug that causes the problem.
As you've probably figured already this isn't going to be easy to debug; ideally you'd have a repeatable failure case to debug, instead of relying on capturing dump files from a remote machine, but until you can make it repeatable remote dumps are the only way forwards.
Dr Watson used to do this, but is no longer shipped, so the alternatives are:
How to use the Userdump.exe tool to create a dump file
Sysinternals ProcDump
Collecting User-Mode dumps
What you need to get is a minidump, these contain the important parts of the process space, excluding standard modules (e.g. Kernel32.dll) - and replacing the dump with a version number.
There are instructions for Automatically Capturing a Dump When a Process Crashes - which uses cdb.exe shipped with the debugging tools, however the crucial item is the registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
You can change your code to add better error handling - especially useful if you can narrow down the cause to a few procedures and use the techniques described in Using symbolic debug information to locate a program crash. to directly process the map files.
Once you've got a minidump and the symbol files WinDbg is the tool of choice for digging into these dumps - however it can be a bit of a voyage to discover what the cause is.
The only other thing I'd consider, and this depends on your application structure, is to attempt to capture all input events for replay.
Another option is to find a copy of VMWare 7.1 which has replay debugging and use that as the first step in capturing a reproducible set of steps.
Right click your executable object and let it be WINXP compatible pending
when you discover source of the problem to finally solve it
I am having an outlook addin which is fairly stable and has been used for years. On a citrix machine environment, the addin is causing outlook to hang if it is left open. Logs are not helping much. How can I approach the problem if I can do the native debugging?
Outlook can hang for many reasons. Since Outlook is COM-based, it uses STA which will cause the main UI thread to hang while it waits for a long-running operation to complete (network call, disk read/write, etc.).
You will need to review the source code to review what behaviors the component is performing when it hangs. Inserting trace statements (Trace.TraceInformation) may also help if you can repeat the hangup. Start with the event ThisAddIn.ThisAddIn_Startup to see the entry point to the AddIn. DebugView is a great utility to view the Trace output of your plugin while it's running.
If COM resources are not being cleanup up properly (Marshal.ReleaseComObject) - over time the memory consumption will grow which will start making the application sluggish - although it shouldn't cause it to freeze/hang.
Your best bet is understanding the behavior of the plugin to see what triggers the hang.
I'm executing a test-execution project using visual studio 2005 (using the pnunit framework and C# but its not relevant). The total execution time is more than 40 hours. In between if there are any environment problems on the network (external factors like remote server is down, db is down etc) the code stops executing. This creates a problem because when I notice the error I'll have to manually set external factors right and again resume the run. So it becomes important to keep checking the execution progress frequently to make sure we are not losing time due to halted execution, which is troublesome.
I looking for a way to somehow either triggering an email/batch script/exe/anything when the code stops running. Is there any way I could achieve this? Any ideas?
Thanks,
Mugen
If you only need to trigger an email at the end of the application, then I would suggest putting the code here at the end of your execution.
Exe made in vb6 will hang if its continously run on server? This exe has winsock component which is used to received data from biometric readers and saved in sql server 2005. Actually this shows real time list for acceess made on biometric readers means in this exe we have used datagrid component which display saved records in sql. How to refresh this exe and data.?
Well, if you're displaying a GUI then I'd say technically you are not running on a server. But I still don't see how doing this will make the program "hang."
There are some things to be careful of when it comes to VB6 memory leaks. One thing to be sure to do is make sure you use the SP6 version of the VB6 runtime and "extended runtime" (the set of controls that ship with VB6). The other is probably to go over the code and look for circular object references that may result in accumulated orphaned objects over time. There were also a few obscure ADO memory leaks that never got fixed until MDAC 2.7, but most of those don't impact a VB6 program.
I suspect there are other causes of hangs, but most of those are probably faulty logic such as loops containing DoEvents calls. Using Winsock for TCP without a full understanding could also produce programs that seem to work at times and then hang awaiting something that nevers happens other times. Remember, on every DataArrival event you can count on at most one byte of data - you need to write your own stream assembly and message parsing logic. One SendData call at a sender does not equal one GetData call at the receiver!
Sent: abc
Received: a
bc
If the program calls GetData until it gets "abc" it will never see it!