Recently, we have met a problem in our product which is a winforms application, a large number of controls are added in the form. But it seemed a little slow when launching the application. When we used the profiler we found that InitializeComponent() is taking 47% of the total time. Profiling indicates that almost all of this CPU time is spent calling the various InitializeComponent methods of all the different UserControls. We want to reduce this time Please let me know if there is any way.
We have come across https://www.infragistics.com/community/forums/f/ultimate-ui-for-windows-forms/105898/run-time-screen-open-delay
which suggest using NGEN if the project is referencing .NET 4 or higher, there is an issue in .NET that causes the dlls to be JITed slowly. But our application is not of .NET 4 or above.
The application is a conversion from vb6 to vb.net and also uses com control and array controls .
Related
I have an vb.net application I distribute to my analysts – We assign perhaps 100 200MB images at a time. The app sequentially opens the large jpg image using GDI+ and the image is placed in the LOH. I scan each pixel looking for data. - when done I dispose the image and use GC.collect. But this does not clear the LOH, and as a result the LOH keeps increasing until the app crashes. A work around is to chop the assignment into 25 instance chunks, but this is risky as our analysts often do this late at night – perhaps after a beer or 2.
The C# construct is
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce
but there is no GCSettings available in vb.net
My vb.net code is
loadedImage.Dispose()
MasterImage.Dispose()
GC.Collect()
Finalize()
But I cannot find a vb.net method to force the LOH compaction
When done
Can you help?
GCSettings.LargeObjectHeapCompactionMode was added in .NET 4.5.1. It exists in VB.NET as well as C#. You're probably targeting a lower version of the .NET runtime. If you want access to this feature you will need to compile against a framework version of 4.5.1 or higher.
This likely won't solve the underlying problem, however. Your leak may not even be where you think it is. Profiling your application with an allocation profiler is the best way to track down resource leaks. Without a Minimal, Complete, and Verifiable example, it is difficult to guess where your application may be going wrong.
I currently have a program that was written in VS 2010 vb.net and compact framework 3.5 and is running on windows CE 6.0(COMTECH CUWIN 5000). This hardware uses an SDK as well
The program reads from Comm ports on a timer, does calculations, displays on the CE screen then sends a string over a Comm port to another computer.
My program is crashing due to memory full every 8-10 hours or so and I cannot figure out why.
I have tried adding a garbage collector at the end of one of my timer ticks but that has not helped only slowed the problem.
A copy of my solution can be found here if you would like to take a look and figure it out.
https://drive.google.com/file/d/0B3bLK_ChVJk-OUJHeXk0cWJqdU0/view?usp=sharing
This solution was translated from VB6. Also I an new to programming so I have a beginners knowledge base to work from.
Thanks in advance
John
I work on a Classic ASP web application that uses several old COM components written in VB6. All of the VB6 components are registered in a COM+ application that run in their own dllhost process. A large majority of the application has been converted to .Net, but there are still a lot of legacy pages and components. COM Interop is used in both directions, calling some .Net assemblies from classic ASP and VB6 as well as calling VB6 components from ASP.Net. The application is running on Windows Server 2008 R2 (IIS 7.5) in the classic pipeline mode.
For the most part the application works fine. The transition to .Net effort was ultimately abandoned, with a new product being developed instead. In the meantime, the old product must be maintained in it's heterogeneous state.
I am having trouble tracking down an intermittent problem where the web application hangs. Users just see a blank screen while their browser waits and the server never responds. The hang persists until I manually kill the dllhost process that's hosting the VB6 components, so I believe the problem is buried there. Probably a memory leak or runaway circular loop.
There are thousands of users on the system daily, but the problem only happens once or twice a week. Fortunately we have a web farm that automatically pulls a server out when it stops responding, so the customer impact is zero. Still, I would like to figure out what's going on.
I have recompiled all of the VB6 components to include debugging symbols and redeployed to production. When the problem happens, I use the 32-bit task manager (c:\windows\syswow64\taskmgr.exe) to take a crash dump of the dllhost process. I end up with a dllhost.dmp file, which I bring down to my development workstation and open in VS2010. I have the .pdb symbol files that VB6 created in my symbols path. When I start the debugging session in VS2010, I can go to the Modules screen and see that indeed all of the symbols for my components are loaded.
Where to go from here? The call stack doesn't show any of my own components. It looks like this:
The disassembly at the top of the call stack looks like this:
Not sure what else I can do. I examined all of the locals at every frame of the call stack and it's gibberish to me. I don't see any references to any of my own components.
Perhaps WinDbg would yield more information? Not sure where to start with it.
I'm pretty sure that if I could just find what VB6 class/method was being called when the hang occurred that I could get to the bottom of it. I've tried adding some logging, and the results are inconsistent.
Perhaps there's nothing wrong with my VB6 components at all, but I'm hitting on some bug within Windows or IIS?
Any advice would be appreciated, but throwing away VB6 is not an option at this point. Thanks.
Not a complete answer, but CoRegisterSurrogateEx is documented to block as long as the surrogate process is running:
The CoRegisterSurrogateEx function is a blocking function. It does not
return until COM+ has determined that the process will be shut down.
Before calling this function, initialize COM on this thread as a
multi-threaded apartment (MTA).
So I don't think the error is on this call-stack. (You can see it was still blocking on a WaitForSingleObject call, most likely the mechanism it uses to block until the process is to be shut down).
I am getting a System.OutOfMemoryException from my vb.net application, it happened from one certain user. I am trying to figure out whether my application takes too much memory space or the PC has low memory. But she just upgraded her desktop as i3 Intel CPU and higher memory.
Is there any tool that I check memory consumption when code is executed as go through lines?
By the way, it is developed by vs2010 and It is a Windows application.
<--Edit-->
I found the problem from my application. I did not mention because I did not know what the problem was. I am using a Google map inside of vb.net application. It takes a memory whenever I search a map on web browser which is on a form . Even though I close the form, it is not disappeared from
memory. It is just going up. That goes away when I close MDI form. FYI..
The best tool we've worked so far is the JetBrains profiler (http://www.jetbrains.com/profiler/features/).
That's a common error. It normally happens when the application enters a loop that never ends... (infinite loop).
Is it a Console, WinForms, ASP, WPF?
Try to identify during which Event your application throws the exception and put a try catch to print out more details.
Just check out this cool WPF performance suite to check out if you have memory leaks:
Performance Toolkit
Or check out if you can use GC.Collect() to find the leak.
Also you can accecss in Process Explorer to any .Net memory data and peaks.
Regards
I am porting VB.Net 2 code (VS 2005) to VB.Net 4 (VS 2010). So far things have been going relatively smooth. However, in testing my new ported code, I came across a strange behavior.
In VS 2005 (.Net 2), I have a DataTable filled with data. I then use a DataAdapter to send updates back to the SQL Server. When I perform the SqlClient.SqlDataAdapter.Update() command, it execute in roughly 4 seconds. The same code, on the same table in VS 2010 (.Net 4) runs in 1 Minute 17 Seconds. This is completely unacceptable. However, I have no clue as to why it is happening. The .Update() method is an internal command, not one that I modified in any way. It does not error out, it's just painfully slow.
Anyone have any ideas?
After many months of working directly with Microsoft...a solution/answer was found.
I don't feel so bad because it took six different Microsoft programmers and almost six months of time to discover the answer. Apparently, Visual Studio 2010's IDE behaves significantly different than it's Visual Studio 2005 counterpart. When running an application in the IDE, VS2010's hook into the running executable actually hinders the applications performance considerably. There is a hidden option (not found in the menu structure) to run the application without the debugger attached. The hotkey is CTRL+F5. When the application is run in this mode, our performance issue vanished. It's such a silly and simple answer...but the two things that make me feel better is that VS2005 did not have this issue, the "run w/o debugger" options isn't listed in the menu at all, and it took six Microsoft programmers to determine this was the issue.
So for anyone else that seems to have this same issue...try CTRL+F5. :-)