Seem to be getting the following daily error with an application and can't see the cause;
Nothings changed to the mapping process within the orchestration
Nothings changed to the content of the data being fed into the mapping process within the orchestration
StaffApprasial.Maps.EmployeeDetails_To_SPList. Error:Transformation failed..
I've looked at the Orchestration Debugger to follow the flow, and can see where it's happening, but there's been no changes to this applications process or functionality to cause this, so I'm out of ideas as to where to look next.
Thanks
I suggest to catch the message from the debugger contexte and run the MAP from visual studio
Related
In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:
'ScriptNS0:DoSomething()' has failed.
Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.
This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.
I realise this is a rather vague question, but does anyone have a clue what's going on here?
You'll have to test this out in Visual Studio. A few things to keep in mind:
It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.
In general, I always try to do the following in custom functoid scripts:
Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.
I am seeing error in IIS Log, Is there any way to know more info about this? We have multiple .NET apps running on IIS.
An unhandled exception occurred and the process was terminated.
Application ID: DefaultDomain
Process ID: 7284
Exception: System.AppDomainUnloadedException
Message: Attempted to access an unloaded AppDomain.
StackTrace:
http://support.microsoft.com/kb/919789
Get crash dumps first, and then use Debug Diag or WinDbg to analyze the dumps. You will see all necessary information from it if you are familiar with the tools.
Microsoft support guys can also help if you open a support case via http://support.microsoft.com
You need to start looking deeper. Perhaps with logging and perhaps running the application in isolation with probes.
Is it a problem? If not stop perhaps?
First check the windows logs and look for more information.
Next check the IIS logs to see if anything is recorded there
Next if you can duplicate the error, try and narrow down to the steps to the bare minimum.
Does it occur on one machine, many machines, on euser many users etc etc...
Try run the app in isolation.
Attach a debugger to the IIS process and see if you can catch this exception alone. If you can then perhaps rebuild the code with symbols to give more information.
Try all these and see if you can find it.
we are getting a stack overflow in production ~ 2-4 times / day
We cannot reproduce this is in dev environment, nad given this is a web app with probably ~100 concurrent users at any one time, I'm struggling to work out how best to track this down.
Is there anyway to get any more info from event viewer - happy to install some form of listener tool - even if i can just get teh thread identity (set to the current user) that'll help - although the dll + class / function woudl be great!
Or is it just a matter of digging, trying to reproduce or adding some tracing in??
There is an IISDiag tool that you can run on production IIS to analyze crashes. Some information here:
http://support.microsoft.com/kb/919790
It's not just for leaks -- it dumps something like a CORE file that you can analyze later.
Slap on Elmah for exception logging. Adding logging of unhandled exceptions using Elmah only require you to drop in the assembly into the application bin folder and to add Elmah section in the web config for a basic logging scenario.
If the logs is not enough to determine the error source you can create memory dumps of the state of the failing application using DebugDiag. There is a guide on how to use it here.
You can put a global exception handler in the global.asax file. Put an exception handler in and then write the stack trace to the event log. This article has a pretty good summary of how to do it though I'm sure there are a lot of others too. Once you know where the error is occurring you can put in some additional logging in the function that the error is occurring in and hopefully narrow it down until you find the specific problem.
I've written a c# windows app, that performs some DB intensive operations. (MySQL connector v6).
When running the project in Debug mode, everything works fine. However, when I run the prject in release mode, it sometimes quits operation midway - with no error message, nothing in the event logs etc.
What would be the best way to debug release mode - when everything works in debug mode?
Thanks for any help,
Bob
You can create a log file and have the application write lines to it with information of your choice, similarly to how the console may be used for debug purposes in a windows form application. You can write values of certain variables to this file, or even just write distinct phrases in select places of the code that will help you detect where the program is in execution when it fails.
Bobby is correct in asking about Application Event Log. If it is bombing on a .NET error, it will likely be logged.
If that doesn't give you anything, wrap the entire app in a try/catch block. On your exception handling, log the error (application log, file, etc...). Make sure when you log it to capture the call stack.
I've got exactly the same problem - application running in debug mode and fail in release. Try the following:
Wrap everything in Program.cs in try{}..catch{} block and it will show a reason
I don't know why but my application failed on Program.SetCompatibleTextRenderingDefault() function with message that it should be called before any instances on IWin32Window or something like that
It is very strange errors for me cuz i didn't have any code before this function. But you can try - maybe it will show something useful for you
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.