I am using the new MessageLoop class introduced in pepper-25 so I can run a background thread with blocking ppapi calls for File IO. Up until now I have been running chrome from visual studio with the flags --single-process and --register-pepper-plugins so I can debug my plugin from within visual studio.
Using these flags I found that the call to PPB_GetInterface get_browser for PPB_MESSAGING_INTERFACE was returning null and after some searching I found this issue which states you must run with the flag --ppapi-out-of-process to get MessageLoop support.
With that flag added get_browser does return a valid interface pointer but I can no longer debug my plugin with the visual studio ide as it cannot attach to the child process that my plugin is run from. Is there anyway to tell it to attach to my plug-in process or a way of running from a single process with support for MessageLoop?
Thanks,
James
To get Visual Studio to attach to child processes automatically, you can use the workarounds described at Can Visual Studio be made to debug child processes like WinDBG?.
A different approach is to use the flags --no-sandbox and --ppapi-startup-dialog when you start Chrome. This will cause a message box to appear with the process id when a plugin process is created. You can then connect the Visual Studio debugger to that process using Debug -> Attach to process... -> pick process id. Of course, you could have attached to the process without the Chrome flags and it's not automatic, so this really just gives you certainty that you're attaching to the right process if you have many running at the same time.
A third approach is to use the free Microsoft-provided debugger WinDbg. It is complex and much less user-friendly than the built-in debugger in Visual Studio, but it does have the ability to attach to child processes automatically. Download is available from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx.
As for MessageLoop it will not be supported for in-process plugins. As the issue you link to mentions, developers should move to out-of-process, even if it adds the inconvenience of not being able to attach the Visual Studio debugger automatically without workarounds.
Related
Trying to launch the editor from Visual Studio 2013 Ultimate I get the following error in the title. VS says it's because it can't reach MSVSMON.EXE on a "remote computer", the weird thing is that I'm not trying to debug on a remote computer, but rather, on my own. My firewall is ZoneAlarm if that makes any difference.
Any help?
Edit: I've set all in and outbound communication to and from both unreal and visual studio in my firewall to "allowed", yet for some reason it still won't let me debug...
Edit 2: Disabling the firewall entirely does nothing at all.. The error persists
Edit 3: Uninstalling ZA altogether seems to fix the issue
Just a note, so far you've been chasing the wrong problem and have not yet gathered enough relevant facts. The dialog is very unhelpful, this does not have anything to do with a "remote computer".
Msvsmon.exe is used in this scenario because UE4Editor.exe is a 64-bit process. Visual Studio cannot use its built-in debugger, it is a 32-bit process. Debugging a 64-bit process with a 32-bit debugger is not possible. So it has a workaround, it uses the 64-bit remote debugger, C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe. Basically works the same has remote debugging on another machine, except it doesn't use the network to connect to the debugger.
So your firewall settings and the considerable amount of trouble-shooting info about remote debugging you can find on the web or MSDN just does not apply in your case at all. You've been chasing the wrong problem.
Having an issue with msvsmon.exe when debugging 64-bit code is quite unusual, never heard of anybody having trouble with it before. You want to do a basic smoke test to check if it is really a problem with msvsmon.exe or it is actually UE4Editor.exe that puts up a fight.
Create a little do-nothing C# console mode app, just Console.ReadLine() in the Main() method. Project + Properties, Build tab, untick the "Prefer 32-bit" option. This ensures it runs as a 64-bit process. Press F5. If all is well then it starts running and you'll see msvsmon.exe in the Task Manager, Processes tab.
If that does not work either then something is interfering with the process interop between Visual Studio and msvsmon.exe. Usually anti-malware related, disable that first. Next thing to try is to start killing processes one-by-one with Task Manager to find the evil-doer. If debugging the C# app works okay then you have a good reason to visit the UE4 forum to find help.
Update your question with what you've learned.
Uninstall Zone Alarm and everything will be OK.
Our 32-bit C++ application names its threads using the standard approach on Windows. We generate minidumps when errors occur, but when the dumps are loaded into Visual Studio 2013 the thread names are missing. This makes it harder to debug the problem given the high number of threads present.
The only way I've heard of to improve this comes from this Microsoft User Voice posting, where the caller suggests embedding them in a custom stream, and writing a custom Visual Studio extension to rename the threads upon loading the dump. However, this seems cumbersome and apparently adds a lot of time to the loading process.
Is there an easier way to embed thread names in the dump so they "just work" when loading them in Visual Studio?
For reference: we use Visual Studio 2013 to build, our apps run on Win7 or higher, and we use Google Breakpad to generate dumps.
Microsoft has indicated that the SetThreadDescription API will be the basis for any proper support they add in the future for thread names in dumps, debuggers, and/or analysis tools.
Unfortunately it appears that this API is rather new and is not yet supported in dumps, WinDbg, Visual Studio Debugger, etc. There is a User Voice request to add this support, so please vote for it if you would like a way to properly give threads a persistent name.
After some more digging, it seems like one way to do this would be to store a pointer to the name in the ArbitraryUserPointer field of the TEB of the thread.
If the TEB was then embedded in the minidump (which can be achieved with the MiniDumpWithProcessThreadData flag, according to this article) then it seems like at the very least we could view the current thread name in the Visual Studio watch window by evaluating
(*(char **)(#TIB+0x14))
Perhaps a Visual Studio debugger add-on could be written to examine the contents of the TEB when a process is attached to, and use the exception 'hack' to set the name of the thread in the Threads window.
I am trying to measure the performance of some functions and methods of a console application project in Visual Studio 2010.
I configured the profiling method to instrumentation. The problem is that the performance monitor doesn't work. The message that I get to the output is:
Profiling started.
Instrumenting w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 10.0.40219 x64
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe --> w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe
Original file backed up to w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.orig
Successfully instrumented file w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Data written to w:\MyProject\ProfilingTest\ProfilingTest110611(17).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Profiling complete.
I presume that the "root of all evil" is:
The process cannot access the file '...' because it is being used by another process.
Did anybody faced such problems trying to profile native applications developed in Visual Studio 2010 and solve them?
Later add:
If, instead of choosing a project to profile, I am choosing directly the built executable, I succeed to profile, without receiving process blocking, I even received the file analysis. However, the monitoring application is crashing at the end of the profiling. I suspect is related to IDE, but I can't tell for sure.
from the performance wizard choose executable as your target and give the path to the executable. This solved problem for me.
Use process explorer's find handle feature (ctrl + F) to figure out which process has ProfilingTest.exe open. That'll get you to the next step of the troubleshooting process.
Another work-around that I found was to do the following:
1) Launch performance wizard
2) choose your project
3) un-check the box to automatically start your profiling
4) Choose "New Performance Session" and choose your project again (top button on Performance explorer window)
5) Select your performance session from "Targets" and choose "Start Profiling"
I wonder if the nice folks at Redmond have taken notice of this..
Regards.
We have an application that allows a user to drag a picture to a window and that window is a drop target (using OLE). When this code is run in the debugger and the Visual Studio instance is run as administrator (right click from desktop) then the target drop is not allowed.
If the exe is run on its own it works fine.
If the visual studio instance is run NOT as an admin the functionality works fine in the debugger. (Same solution/project files/etc)
Win7 OS. Visual Studio 2008. Unmanaged C++
I find it very odd. Not sure why it is happening. In fact I would have guessed the OPPOSITE regarding running VS as an admin.
Has anyone seen this or does anyone have links to workarounds or explanations?
This is most likely happening due to UIPI (User Interface Privilage Isolation).
In the case where you've launched your processes as Admin (due to the parent process (Visual Studio) being run as admin), UIPI isn't going to let non-elevated (admin) processes send any messages to your app. Drag and Drop between applications is implemented using Windows messages.
To work around this, you can use the ChangeWindowMessageFilterEx() API to opt into the appropriate drag and drop messages.
If you want to really and truly fix it, then you would need to
Detect when your process is running elevated
Spawn a non-elevated helper process which registers as the drop target
Pass the dropped data through IPC to the elevated process, using a method that's safe to use across privilege boundaries (i.e. no active objects which carry code)
This is a LOT of extra work when the workaround could be as simple as dropping from another elevated app (to get an elevated Explorer, just call up the File->Open dialog of any elevated app), but has the advantage that drag-and-drop will work properly if any of your customers ever run the app elevated.
Unfortunately this looks like a flaw in the OS:
http://blogs.msdn.com/b/patricka/archive/2010/01/28/q-why-doesn-t-drag-and-drop-work-when-my-application-is-running-elevated-a-mandatory-integrity-control-and-uipi.aspx
Oh well.
I find this whole issue appalling. MS has screwed up on this IMO. Essentially we can't debug an app correctly if I want to run MSVC in elevated mode (for example when I build the solution it registers COM servers).
http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/2fa935cf-be57-4bcc-9b96-7ee5a6b2b7a5/
I'm trying to debug shell extension (IContextMenu) in Windows 7 with Visual C++ 2008. I have set DesktopProcess=1 in the registry and set host app to explorer.exe. But when I start the debugger, it launches explorer.exe and then detaches from the process. DllMain of the shell extension isn't called.
The same code with exactly the same settings launched in debugger without any problems in Windows XP + Visual C++ 2008.
Any thoughts how to debug the shell extension in Win7?
I've found a nice workflow that I think is the fastest way to rapidly iterate the code-build-test cycle when developing shell extensions. The following should work on any Windows version.
First prepare - set the start program of your shell extension project to be c:\windows\explorer.exe and also set it to be the start-up project.
Then, whenever you want to debug your shell extension perform the following steps:
Click on the task bar and press Alt-F4 - this will bring up the shut down dialog
Press Ctrl-Alt-Shift-Escape - this combination will close explorer.
Use Alt-Tab to go back to Visual Studio and press F5 - explorer will now launch with the VS debugger attached to it from the very beginning.
When done, just stop the debugger session. This will kill the debugged instance of explorer and will also automatically start a normal instance of it. This will also unlock the shell extension DLL so that you can build it again.
Caveat on Vista and 7 - be sure to run the Visual Studio that you use for debugging in non-Administrator mode (non-elevated), so that the explorer is started in its usual non-elevated mode.
Try launching explorer and THEN attaching the debugger to it.
You could try putting a DebugBreak() call in your code. This should launch the just-in-time debugger at the call and give you an idea of what is going on.
You should take a look at gflags.exe, part of the standard debugging tools sdk. It's got all the options you need to configure (global)flags for any process startup/services/heap/pool-tagging/stacktrace's-on-allocation etc...
Debugging Explorer.exe is usually overkill for extensions that operate in a shell view.
I personally use a little app I made that hosts an instance of IExplorerBrowser similar to this example. If your IContextMenu item is not the default item then you can just use Notepad.exe and its open file dialog...