I just discovered SOS Extensions and am trying it out with a stupid hello world console app in Visual Studio 2010. I have enabled debugging unmanaged code and executed .load sos on my project properties. However, when I do !Name2EE App.exe!Program I only see the Module and Assembly info. I don't see the MethodTable or anything else:
!Name2EE App.exe!Program
Module: 001c2e9c
Assembly: App.exe
Can anyone shed some light on why I'm not seeing the rest of the info?
Try using actual type name including namespace:
0:000> !Name2EE HelloWorld!MyCompany.HelloWorld.Program
Module: 00182e9c
Assembly: HelloWorld.exe
Token: 02000006
MethodTable: 00183888
EEClass: 00181794
Name: MyCompany.HelloWorld.Program
If you specify a filename with extension, separate the module from the type.
!name2ee app.exe Program
-OR-
!name2ee app!MyApp.Program
Also, as the previous answer indicated, always use the FULL type name.
Related
I'm getting the same error message as in this question: Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService' Unfortunately, I cannot upgrade to Azure SDK 2.9, as the top answer there suggests.
Specifically, I get this error in a message box whenever I try to package my Azure Cloud Service project:
What's interesting is that I can start the same project in the emulator, which I would assume involves packaging it.
Things I've tried:
Ensuring that I only have version 2.8.2 of the emulator installed (I may have had 2.9 installed initially)
Reinstalling version 2.8.2 of the SDK
Manually copying the Windows Azure Tools from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 to the v14.0 equivalent.
Ensuring that C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8 exists
Reinstalling Visual Studio (so you know I'm desperate!)
And I've no idea what to try next. I can't work out which DLL is supposed to hold the Microsoft.VisualStudio.WindowsAzure.Services assembly, I can't find any references in any config files, and all the Google hits seem to point back to the SO question linked above.
What's going on? And how can I fix it?
In case I'm being an idiot, here's all the Azure-related things I've got installed:
Also (just in case it's relevant) I'm on Windows 7 SP1.
Update 17/01/16
Following some advice from the excellent Rest Azured Slack channel, I've tried using ProcMon and Fusion Log to diagnose this (spoiler: without success)
ProcMon filtered to that assembly returns nothing:
Fusion log (set to log everything) yields lots of entries like this:
* Assembly Binder Log Entry (17/01/2017 # 11:52:02) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.WindowsAzure.Services, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio
14.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = devenv.exe Calling assembly
: Microsoft.VisualStudio.WindowsAzure, Version=2.9.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
=== WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with
Assembly.Load(). WRN: No matching native image found. LOG: IL assembly
loaded from C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Microsoft.VisualStudio.WindowsAzure.Services.dll.
When I explore the DLL mentioned, I can find Microsoft.Cct.Services.Sqm, but it doesn't contain a type IWatSqlService:
This feels like it's the crux of the issue, but I've no idea what to do next. Presumably I'd need to replace the DLL with a version that does define IWatSqlService, but I'm not sure where I'd get one. Or, for that matter, why it would even be necessary.
Next stop is probably a full wipe of the machine.
I've had the same problem, and solved it by not using the Web Platform Installer.
Download all parts (Microsoft Azure SDK for .NET - 2.8.2) from the Microsoft site: https://www.microsoft.com/en-us/download/details.aspx?id=50041 and follow the instructions how to install them.
For anyone else with this problem. I ended up resolving this by nuking it from orbit. Fresh install of Windows, reinstall VS and the SDK.
Confusingly, you can also see this error when you add a new
<setting name="TODO" />
element to your *.csdef file but either:
forget to add the corresponding <setting name="TODO" value="TODO" /> element to every *.cscfg file, or
accidentally add a duplicate <setting name="TODO" value="TODO" /> element to any of the *.cscfg files.
I have a UWP app that compiles successfully if I have UseDotNetNativeToolchain off. But when I turn it on, it gives me the cryptic error:
Internal compiler error: Object reference not set to
an instance of an object. UWPApp C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets 887 Build
This is all it gives me. What could be causing this? How can I drill down on this.
Using VS2015
Here is the full build output in case that helps:
https://gist.github.com/shannah/e24fe8456313fb9ad98577c9a812f357
The solution to this problem was to disable optimization in a few assemblies I was using in the Default.rd.xml file. E.g.
<Assembly Name="IKVM.OpenJDK.Core" Dynamic="All" DoNotInline="true" DoNotOptimize="true"/>
This is a super weird question for Visual Studio 2013: Windows Forms Application 3.5!
I designed and made the program, then I ran the program for the first time and an error pops up.
And then I click cancel, retry and this time I click yes and this pops up:
Error while trying to run project: Could not load file or assembly
'SourceProject' or one of its dependencies. The located assembly's
manifest definition does not match the assembly reference.(Exception
from HRESULT: 0x80131040)
Any ideas on fixing it?
FULL ERROR LOG
Error 1 Unable to copy file "obj\Debug\SOURCEPROJECT.exe" to
"bin\Debug\SOURCEPROJECT.exe". Access to the path
'obj\Debug\SOURCEPROJECT.exe' is denied. SOURCEPROJECT
Just open your Debug Configuration near by Application Run Button in VS. Then , Choose debug with Any CPU to x64 or x86 .. May be it will help someone.
Thanks,
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.
I have a minidump from a customer. I want to find out the assembly versions of the loaded .NET dlls. I've already searched the internet for hours now, but cannot find a usable way.
I have windbg and have loaded SOS extension an have the needed clr.dll and mscordacwks.
using lm -v only shows the unmanaged dll's. I am sure I am overlooking something very simple.
WinDbg's lm v shows all DLLs, managed and unmanaged. On that level, an assembly is just a DLL, is just a module.
With WinDbg 6.3.9600, lm v even shows information whether a modules has a CLR header or not:
0:008> lmv m MyApp
start end module name
10310000 10574000 MyApp(deferred)
Image path: C:\...\MyApp.exe
Image name: MyApp.exe
Has CLR image header, track-debug-data flag not set
Timestamp: Wed May 21 16:34:02 2014 (537CB95A)
...
ProductVersion: 1.8.0.44
FileVersion: 1.8.0.44
...
However, the FileVersion and ProductVersion is still unmanaged information compiled into the native resource part of the DLL.
I suggest you use !SaveModule <start address> <filename> to save the file on disk and then use a reflection tool like dotPeek to open it and get the assembly information from there, which will give you the name, version, culture and public key token.
To save all modules, Naveen has written a script like this:
!for_each_module .if ($spat ("${##ImageName}","*.exe")) { !SaveModule ${##Base} c:\temp\${##ModuleName}.exe } .else { !SaveModule ${##Base} c:\temp\${##ModuleName}.dll }
Alright, after some more research I came to the conclusion that that kind of information is just not available for those dll's in a minidump. Anyway I was at least able to get some more information about the files, and maybe this is useful for someone else in the future.
You can get at least the metata information of the dll's, and maybe you can find something useful in there. Here's how to do that:
First get the domain:
!dumpdomain
You might end up with a large amount of listed assemblies. Now you can either look them up by hand using:
!dumpassembly ADDRESS
or you can just use the lazy way: Install the python extension for windbg (http://pykd.codeplex.com/) and use the following script for a quick overlook (it's maybe not the nicest script, but it's working and I didn't want to invest more time):
import pykd
def dump_assemblies():
assemblies = 0
addrs = pykd.dbgCommand("!dumpdomain").splitlines()
for x in addrs:
if x[:8] == "Assembly":
assemblies = assemblies + 1
print "### retrieving assembly " + x[-8:]
print pykd.dbgCommand("!dumpassembly " + x[-8:])
print "### found " + str(assemblies) + " assemblies."
dump_assemblies()
You will now be able to do a text search (CTRL + F) for the dll. Once you found it, you can find the offset next to the module name (looks something like 12327C8 C:\Program Files\MyApp\MyDLL.dll).
You can now dump the module using:
!dumpmodule 12327C8
which will lead you to:
Name: C:\Program Files\MyApp\MyDLL.dll
Attributes: PEFile
Assembly: 131a22e2
LoaderHeap: 00000000
TypeDefToMethodTableMap: 19220010
TypeRefToMethodTableMap: 134303e0
MethodDefToDescMap: 13430740
FieldDefToDescMap: 13433964
MemberRefToDescMap: 134350c8
FileReferencesMap: 13435918
AssemblyReferencesMap: 1343591c
MetaData start address: 1c1aaa4c (4248 bytes)
Now you can check the metadata of the dll simply with:
dc 1c1aaa4c 1c1aaa4c + 4248
That's the closest I could get to more information about the DLL. Unfortunately the file version was not written there, just some other more generic info. Anyway, I will try to get in touch with the customer again. Thanks for the answers anyway.