When I attach to a process, wfica32.exe I get a message saying "no source code available". This application launches through Citrix.
Of course I have no issues attaching to this application and viewing its source code when it runs locally. Unfortunetly, the error I experience only occurs when running through Citrix. I suspect a race condition.
I added the *.pdb files to the server. Is it possible to attach to a process and see source code in a Citrix session?
You can't expect to be able to debug an application that runs on a remote computer you are connected with, attaching debugger to Citrix Client process (wfica32.exe you mentioned). What you need to do is to setup remote debugging (which might be just impossible in some cases). You can find more information on msdn: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
The PDB files will give you the symbols, but you'll need the source files on the server as well.
Related
I constantly run into problems where a program runs fine on my system (installed and in development environments) but fails on a users system.
The best solution I can conceive is to debug the program on the users computer, but that's not practical since it would require me to install VS on their system and move the source code over (and doing so would compromise the integrity of the test environment anyway since it may cause the bug to vanish).
I want to remote debug but what I'm reading from the MSDN says to me "Nope, you can't do that unless both systems are on the same network (all. my. rage.)" :
Network configuration
The remote computer and the Visual Studio computer must be connected over a network, workgroup, or homegroup, or else connected directly through an Ethernet cable. Debugging over the Internet is not supported.
Is there another option I can use to connect to the process that is running on another system outside my network?
A partial solution (for the case that throws an exception).
Instead of trying to reach client app over the Internet, generate crash dump and debug it locally, in a comfort of your home :). Please see MSDN for details.
You can use a tunneling application (like hamachi). This will allow you to connect the other party like you're on the same network. Then you can use the remote debugging option. But even in local network remote debugging works slow and sometimes fail with code-optimized builds. Before using the "remote debugger" (by assuming there is any exceptions) I suggest to log all exceptions to a log file then watch the system. It will be helpful to put .pdb files to the remote system to see the relations between code.
I have a .Net application that's reporting hangs in the Event Log. The events say "Application Hang" with no usable details to go by.
So I whipped up a C# console app that uses the ClrMD library. But the caveat is this application is being published as a RemoteApp. When I try to attach ClrMD to the users' process I get this error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 0.
This is not surprising since I'm logged into the server as Administrator and they are in their own RDP session with a different user.
So then I decided to impersonate the user they are logged in as thinking if I run my ClrMD app as them, it will have access to that process. This gave me a different error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 1008.
I can't seem to find any clues as to what 1008 means to know where to go from here. I realize I'm probably trying to do something that's not possible.
Has anyone gotten ClrMD to attach to another user's process?
If not, are there are debug tools out there that can attach to other users' processes?
If not, have people used ClrMD in within production and how would I know the app is hung to know when to trigger a ClrMD dump? Just monitor the UI thread in another background thread?
Had / have same issue. Running elevated as admin on a server via a console app didn't work. But it does work if run through PowerShell or Visual Studio itself with elevated permissions. The debugger requires Admin privs to connect live. Adding a manifest, etc didn't seem to help when running as a console.
I have a console application that performs some data work and then closes. If I run the executable manually it opens a command prompt, runs the program, and closes. No issues at all regardless of what Microsoft OS I'm using.
However, if I attempt to run the program as a scheduled task it fails on one specific server running Windows Server 2008 R2. It works as a scheduled task just fine on other servers, including another Windows Server 2008 R2 box in the same building. Unfortunately this one server is the server it needs to run on. I've tried adding logging, writing to the event logs, executing the application as an administration, forcing 32 or 64 bit, and launching it as a separate launch from a .bat file. Nothing. The program isn't crashing, it is just never opening.
Does anyone know what may be causing this? I'm at a loss and I don't know what to do.
Edit: I created a test .bat file that just launches a command prompt to see if it would open a command prompt window. It does not. The other tasks seem to run fine though.
Edit #2: I have been researched this and something that has come up is to set the task to enable with desktop. I can't find that option nor can I think of a reason why it would fix this issue but it seems to keep coming up.
After a bit of fiddling around this is what worked for me. When you point to the console application in the actions Tab, ensure that you fill in the 'Start in' field with the location where the executable is located even though it says that it is optional. Once you fill that in, it will work.
Whenever I debug my application (ASP.NET Web Application converted to Web Role), I am able to get to the login page. I go ahead and sign in, debug through that and it seems to work fine, but as soon as it takes me to the landing page after login, DevFC.exe stops working with the error:
An unhandled exception ('System.Net.Sockets.SocketException') occurred in DevFC.exe [8072].
Now, I've searched for the issue and have seen something about DevFC.exe crashing due to VMWare Workstation that listens on the same port (12000) and HTC Sync that also listens on that port. I have neither of those applications on my machine, so I am lost here. Using TCPView (from Sysinternals), I find no other application using that port.
The one thing I do notice is that [System Process] goes crazy creating connections to localhost:12000 once DevFC.exe gets started.
Anyone have some insight on this?
This might sound ridiculous but restarting your machine might solve the issue. If that doesn't work, try your project on a different machine. If the project works then there is an issue with your primary machine try uninstalling then reinstalling the Azure SDK. If the devFabric still crashes on the secondary machine then it's something related to your project.
You might want to take a look at the logs created in the DevFC folder here: %localappdata%\dftemp\DevFCLogs (C:\Users\[user]\AppData\Local\dftmp\DevFCLogs). This will hopefully shed light on the actual error (which in my case, was a conflict on port 12001. Ran netstat -ab afterwards and found it was vmware-hostd.exe. This is a service included with VMWare Workstation 8. I know you said you don't have that, but you may have some other conflicting software).
See this thread as well for more detail.
http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/7e205afd-4b9a-4387-8e10-99e4b8f27788
I have problematic deployment of my application on some client computer.
I really need to see what is going with my application in the run time and my logging is not sufficient.
The computer is on separate network that I don't have any connection there from my office.
Is there some tool that can record the execution of my application?
At least inputs outputs of functions?
Your hurdle here is that the target machine is on a remote disconnected network from your own, which makes use of the Visual Studio Remote Debugger tool useless (unless you're able to open firewall ports to the target machine, or establish some kind of VPN).
Try The Remote Debugger, install a VPN client on your machine and theirs (Hamachi is a good example), then the remote debugger should function (docs on MSDN).
I'd initate normal diagnostic measures
What's special about this machine compared to others that could interfear with normal function.
Can you replicate the target environment.
Is a stack trace available, does it contain any usefull values.
Can you deploy a version to the target that has additional value logging wrapped around the broken function (log all values before hitting the code that can cause the crash).
Visit the site with the target envirnment, and run the remote debugger from within their network.
Install Visual Studio (and all your source code) on that target machine and debug from there (kind of extreme).
I have found mdbg most helpful in these situations.
Just copy it to a flash disk.