I'm running a .NET 2.0 program on many computers. On one I had this error occurring repeatedly until I reset the application.
//line below was throwing the exception
this.myButton.BackgroundImage = global::myNamespace.Properties.Resources.myImage;
Exception:
ExceptionType: ArgumentException
Message: Parameter is not valid.
Source: System.Drawing
StackTrace: at System.Drawing.Image.get_Flags()
at System.Windows.Forms.ControlPaint.IsImageTransparent(Image backgroundImage)
at System.Windows.Forms.Control.set_BackgroundImageLayout(ImageLayout value)
The resource exists and it works fine once reset. Can anyone provide any insight as to might be happening?
I suggest you use Process Monitor to examine real-time activity on the file, and which processes might be locking it. Add a Filter where the Path is the name of the image/resource file; this should quickly show if anything is monkeying around with the file behind your back.
Yes, this is a 6 year old post! Ran into the same error today, and it took me far longer to fix than it should have. I was actually disposing my image control on startup, so I obviously couldn't adjust its background image on run-time. Might as well double check for that if you're here.
Related
I am working on a universal 10 application,at first every thing works fine but after I get a strange error:
Processing Resources failed with error: double entrees
I tried to find some information on the internet, but nothing. Also when I double clicked on the error it doesn't bring me to the error's spot.
I have tried to do many things,like searching in the .resw file(s) and nothing helped, so I decided to write this post
Can someone help me resolve this errors?thanks for help
The error seems to indicate that you have a duplicate resource in a resource dictionary.
Try going through the resource dictionaries and removing any duplicates.
Another approach is to compare the source files you have now to ones that were previously compiling without any issues and see if you can narrow down the culprit.
I have a WinForms (.NET C#) OLTP application based on Oracle.
From our support environment we regularly experience loss of connectivity to the database, and a resulting minidump file is generated (by what, i am not entirely certain of) - apparently it does not cause the application to crash, but in order to actually do anything you have to close it and start it again.
After a many such minidumps have been created in the same directory, all of a sudden the minidumps starts getting rather strange file names, filenames that are apparently "illegal" on windows.
For instance we have a file name like:
"°÷ƒ
_minidump_default_pid_20248_tid_x19AC_2015_9_1_8_31_51.dmp"
And yes the carriage return is PART of the file name.
We discovered this because log4net watches the directory and all of a sudden starts to bark unhandled exceptiosn due to these invalid file names.
So we are trying to figure out why the minidump is generated in the first place, but the question here is, can we somehow prevent the minidump from being generated with an invalid filename or otherwise control the naming process?
Secondly, does anybody know why is it even possible to create invalid file names in the first place?
Update:
For anyone looking at this trying to figure out why the dump files are created in the first place, our issue was that Windows was generating them when it was near running out of memory, but for some reason we would'nt always get an OOMException.
First, you should really try to find out how those dumps are generated. Microsoft e.g. provides a nice way using a Registry key called LocalDumps which has provided great help for me. I am sure that this approach won't generate invalid file names like above.
Second, if the application does not crash, it has probably registered an unhandled exception handler. This is basically ok and designed to write crash dumps, but the unhandled exception is handled by the crashing process itself. How can the code to handle the situation be sure he himself is not affected by the crash? The better option is to let Windows as the OS handle the crash. Then the Windows kernel (which is not affected by the crash) can really handle the situation. That's what LocalDumps does.
Third, direct file system access is possible in Windows via paths that start with \\.\ when passing it to the Windows API. Starting a path like that will skip any file name check so you can generate files with reserved characters such as *, ?, : or newlines as observed by you. The unhandled exception handler of your application is probably doing that and is affected by the crash in a way that parts of the file name are overwritten.
Chkdsk should be able to repair the file system.
pls check if you are installing from network path like \remoteserver\d$\client.
then change it to \remoteserver\d\clinet
"$" in share path create issue while extration on elevated permission files
I recently encountered a very weird problem with report viewer (Windows Forms). Normally the reportviewer behaves very well, loads fast and shows the reports nicely. But, we encountered a certain scenario in which it to takes ages to show the report. I cannot post the whole code as it is not clear what causes the problem.
The problem
The following method call causes the problem (again, only in a very specific scenario):
reportViewer.LocalReport.GetDefaultPageSettings()
It can take up to 10 minutes for the application get past this line and in fact, if this line is commented out then everything starts working perfectly.
The special scenario
The only difference in the special scenario that causes the problem is that right before showing the report some python code gets executed before the report is shown (via IronPython and in the same AppDomain, the python code does not reference anything even close to reporting).
Profiler, anyone?
Ok, so I run this scenario with a profiler (Xte) and noticed that the method IronPython.Runtime.PythonContext.LoadAssemblyFromFile is the one that freezes up. There is no explicit assembly-loads in python code we are running, so this is an automated assembly load.
The weird part
So, the weird part that I cannot get is how are those two things connected? I took a look at the GetDefaultPageSettings() in ILSpy and saw this:
public override ReportPageSettings GetDefaultPageSettings()
{
object syncObject;
Monitor.Enter(syncObject = this.m_syncObject);
ReportPageSettings pageProperties;
try
{
this.EnsureExecutionSession();
pageProperties = this.m_pageProperties;
}
finally
{
Monitor.Exit(syncObject);
}
return pageProperties;
}
And I can only guess that its the lock that is causing this method to hang, but I cannot understand how executing python affects this lock. I mean, it is absolutely clear that if I do not run the python code then this method executes perfectly fine without delays.
And by the way - after approx. 10 minutes the thing shows the report. It just locks up for 10 minutes and then continues normally.
Suggestions on where to go from here?
So, I would really appreciate if anyone can give me any info on there should I go now. At the moment I am trying to isolate the case in a separate clean project and as soon as I succeed I will post it here.
Thanks!
Update 1: Python script example
So far I only got one piece of additional information - this problem occurs even if you run a minimal script. So, even executing script 0 (which just returns 0) the problem will occur.
Update 2: Running in a separate domain
Running python in a separate domain did not help. The issue is still present.
Update 3: CurrentUICulture is involved!
During my debugging sessions I noticed at some point that in the problematic scenario AppDomain tries and fails to resolve the following resource assemblies:
mscorlib.resources, Version=4.0.0.0, Culture=fi, PublicKeyToken=b77a5c561934e089
mscorlib.resources, Version=4.0.0.0, Culture=fi-FI, PublicKeyToken=b77a5c561934e089
This is the reason for the 10-minute delay - it just tries to load that assembly over and over again (both CurrentCulture and CurrentUICulture are set to fi-FI). If, however, I change the CurrentUICulture to en-US then the problem disappears (as it not longer needs that assembly.
But again - the mystery still remains - if the CurrentUICulture is set to fi-FI and I execute any script via IronPython it will desperately try to load this resources file and fail all the time. If anyone is able to explain this to me - please do :)
The text in Update 3 actually contains the resolution. At the moment the only solution I know is to change the CurrentUICulture to en-US for the moment when the report control is loading and rendering. This effectively eliminates the 10 minute delay.
I apologize in advance if this is really a Super User question... I just wasn't sure, but this seems more on the dev. side than on the tech support side. :)
This isn't necessarily a problem, but it does actually drive me totally bonkers on my system. It also only happens on my computer.
When I launch any application, even a blank WPF application, I see four exceptions:
A first chance exception of type 'System.IO.DirectoryNotFoundException' occurred in PresentationCore.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in PresentationCore.dll
To figure out where these are coming from, I then set VS2008 to break on any thrown CLR exceptions, and here is the information:
Exception #1:
Cannot find a part of the path 'D:\Dell\Reader2.0\SPLASH.SYS\fonts\AscenderUni.ttf'.
Exception #2:
Culture name 'ug' is not supported.
Parameter name: name
Exception #3:
Culture name 'ug' is not supported.
Parameter name: name
Exception #4:
There is no registered CultureInfo with the IetfLanguageTag 'ug'.
I've poked through Process Monitor and Process Explorer. Process Monitor shows that my application is doing a RegQueryValue, which I'm certainly not responsible for... but some DLL (presumably from Dell crapware) is getting loaded by my process and is reading this regkey. I then looked at Process Explorer, hoping to see which DLLs my application is loading, but can't find that info. I then tried PrcView and saw the modules my application was loading.
I was surprised to see how many other modules were getting loaded, but I didn't see anything Dell related. I'm also wondering how it is possible that a Norton Internet Security DLL got loaded into my process, but I assume that's intended and something special that Norton does to ensure that a process is safe to execute.
What else can I do to identify and remove where these exceptions are coming from?
UPDATE
Not sure if it's confusing what I'm getting at here. This exception is raised in a DLL that my application loads for some reason (I don't reference anything Dell-related from my project). I've now uninstalled that app, and I still get the stupid exceptions. It's all technically fine because the exception is handled somewhere, presumably within that DLL, but I'm just annoyed because four extra messages (actually 8, since I have to close two dialogs per exception) pop up when I run my application. Call me lazy, but I never asked this damn DLL to load in the first place. :)
Perhaps now it's time to use msconfig to start disabling some Dell services. I'll play with that later when I actually have free time.
No file corruption. As I've been trying to hunt this one down for a while, I figured out what happened. Somewhere along the way, a font was installed with Uighur culture, which is, apparently a Turkish/Chinese culture (as best as I can tell), and their CultureInfo tag? "ug". When the fonts were cached, the system was attempting to load the Uighur culture. Sadly, my installation of Windows seems to be conspicuously missing this culture in Windows. Knowing that I won't be using the culture on my machine anytime soon, I followed the directions on MSDN to create and install a new culture.
Though the error won't hurt anything major. It is just a first chance exception, after all, it was annoying the crap out of me. So here's what I did.
Create a new console app.
Add a reference to sysglobal.
Add the following code:
var culture = new CultureAndRegionInfoBuilder("ug", CultureAndRegionModifiers.None);
var ci = new CultureInfo("en-US");
var ri = new RegionInfo("US");
culture.LoadDataFromCultureInfo(ci);
culture.LoadDataFromRegionInfo(ri);
culture.Register();
Build.
From Windows Explorer (you need admin privileges to do this), run the compiled executable as administrator.
If all goes well, there should now be a file in C:\windows\Globalization called "ug.nlp".
You shouldn't receive that message again.
I had the same problem.
It disappear after I did:
Clear the WPF font cache and restarted Visual Studio.
Clear the cache: http://support.microsoft.com/kb/937135
Éric
It is very unlikely to be the shovel-ware on your machine. These DLLs need to inject themselves also into non-managed programs, they have to be written in a language that doesn't depend on the CLR, like C or C++. And accordingly cannot generate managed exceptions.
These exceptions look like machine configuration problems to me. Junk in your registry. The bad culture name (sounds like "us" got corrupted to "ug") generates three of them, the font is probably listed in the registry but missing from the disk.
Short from a OS reinstall, you could possibly diagnose this by using both ProcMon and the debugger. Use Debug + Exceptions, Thrown checkbox to force the debugger to stop on the first-chance exception. When it hits, switch to ProcMon, the registry key or file should be visible very near the end of the trace.
With leads from the above answers I was able to solve this issue by deleting the font "Microsoft Uighur Regular"
First chance exceptions are normal - these are displayed whenever an exception is thrown, whether it was handled or not. They exist so you can go into your code and find out why they are thrown.
However, if the exception has been handled, there is no problem and execution will resume.
If the exception was not handled, a second chance exception will be caught by the debugger and execution will halt.
This is normal and shouldn't be of concern. You can always hide them - see this question and answers for more details.
In regards to the actual exceptions - there is some code (third party or your own) that is trying to access a ttf in the mentioned directory, this cannot be found, hence the exception (which was handled, so no problem).
The other exceptions are due to create a non existing CultureInfo (ug) - perhaps this is supposed to be uk? Check configuration and code for this.
These values may be configured in the registry.
I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?
Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.
Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.
Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?