I'm using debugdiag 1.2 with a .dmp file. I've been working with Microsoft support and we get different function trace details - his version is a lot more verbose with function names and parameters.
I wondered if there was something I'm missing to get the same as him?
For example, I will get:
ntdll!NtWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e5
clr!WaitForMultipleObjectsEx_SO_TOLERANT+62
clr!Thread::DoAppropriateAptStateWait+53
clr!Thread::DoAppropriateWaitWorker+186
clr!Thread::DoAppropriateWait+7d
clr!WaitHandleNative::CorWaitOneNative+151
mscorlib_ni+509aa4
0x000007fd`231e0e5c
mscorlib_ni+4efd85
mscorlib_ni+4efae9
mscorlib_ni+4efaa7
mscorlib_ni+d529ad
For same dump file, he will get:
ntdll!ZwWaitForMultipleObjects+a
KERNELBASE!WaitForMultipleObjectsEx+e5
clr!WaitForMultipleObjectsEx_SO_TOLERANT+62
clr!Thread::DoAppropriateAptStateWait+53
clr!Thread::DoAppropriateWaitWorker+186
clr!Thread::DoAppropriateWait+7d
clr!WaitHandleNative::CorWaitOneNative+151
mscorlib_ni!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle, Int64, Boolean, Boolean)+14
FiftyOne_Foundation!Unknown+3c
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+285
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+9
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+57
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart(System.Object)+5d
DebugDiag looks like a hugely useful tool - I'd dearly like to have a good understanding of it. Thanks in advance for your time.
The difference is that Microsoft Support uses internal PRIVATE SYMBOLS and when you use Debug Diagnostic tool with PRIVATE symbols, the NATIVE stacks displayed in the report are much more accurate and better because the debugger (dbgeng.dll and dbghelp.dll to be specific) are able to figure out even the managed function names and they show those in the native stack as if they are native functions however if we use the PUBLIC symbols (from msdl.microsoft.com) to analyze the dumps, these function names won't show up in the debug diag report under the native stack section.
You should still be able to see the right function names under the MANAGED callstack of the thread in the report
I can also see that the CLR loaded in the dump is 4.0 or above so you will get better stacks in the report if you use Debug Diagnostic 2.0 as that was written specifically to target 4.0 and above framework runtimes. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=40336
Related
Scenario:
My company has a legacy (read that as 32 bit) windows form application that will be around for quite some time in the future. This application uses an embedded web browser control that is supplied pages that are contained within the database that it maintains. It was built like this so we could extend/modify as needed. I say this so that I can validate that security is not a concern. Only the application and developers with the correct tools have access to the pages or database. The application is only available inside the office.
There are some processes that I need to accomplish using ActiveX objects that are embedded within the pages/application. One of the biggest and most annoying thing that happens is the ActiveX security warning when I got to create instances of things like “scripting.filesystemobject”. Example:
Set oFSO = CreateObject("Scripting.FileSystemObject")
My solution is to create a DLL that is installed locally on each machine that needs access to the extended functions, have the all the functions (whole DLL ??) marked as safe so that the web browser control does not present the security warning. I have been searching using google and came across very few examples, and all of which are in C# which is not my strongest language.
I’ve had to convert from C to Vb.Net visual basic to get what I have now. When I go to register my DLL, I get the following error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>regasm
Z:\VBNet2017\APIInternal\APIInternal\bin\Debug\APIinternal.dll /tlb
Microsoft .NET Framework Assembly Registration Utility version 4.8.4084.0
for Microsoft .NET Framework version 4.8.4084.0
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
RegAsm : error RA0000 : Type 'APIInternal.API.Accupay' has an invalid default COM
interface: 'APIInternal.API.Accupay'
UPDATE: Thank you Hans; the error is gone. I've also made some changes in the source code; I changed the ProgID to something that closely resembles where and what this is for. I'm still having issues in creating the object in VB Script.
This is the output from the current version of the code. This is the code, stripped down for clarity:
Option Strict On
Imports System.Runtime.InteropServices
Imports System.IO
Namespace API
Public Interface IAccupay
<DispId(1)>
Function GetFiles(ByVal Folder As String) As List(Of String)
End Interface
<Guid("8B4B5CEF-8B3A-49A1-9053-E909F82D9E73"),
ProgId("AddIn.Accupay"), ClassInterface(ClassInterfaceType.None),
ComDefaultInterface(GetType(IAccupay)), ComVisible(True)>
Public Class Accupay
Implements IAccupay
Private Function GetFiles(Folder As String) As List(Of String) Implements IAccupay.GetFiles
Return Directory.GetFiles(Folder).ToList
End Function
End Class
I have tried just about every combination of ProgID, Name space, Interface name and class name to get this error to go away without any luck. I do know there are other elements that need to be addressed or added, such as error trapping and, if I’m not mistaken, how to actually implement the ObjectSafetyOption which I still don’t know how to do.
I have been using the Guide at the bottom of this article:
Is it possible to mark an ActiveX object as safe so that IE settings need not be changed?, the second answer, but I haven’t had any success.
Please, can someone point me in the right direction, maybe show me what’s wrong with the code that I have and how to physically implement the ObjectSafteyOption that is needed for the web control. Links, additional reading, code examples or comments on how to get this fixed and working would really be appreciated.
Thank you for reading and any help you send my way, Fred
PS: If you need more information, or have a better solution, please don’t hesitate to reply or comment.
UPDATE:
With the code that I have now, I am able to access the DLL in VB.Net visual basic:
Imports System
Imports APIInternal.API
Module Program
Sub Main(args As String())
Dim API As New Accupay
Dim FileList = API.GetFiles("C:\Windows\")
For Each Item As String In FileList
Console.WriteLine(Item)
Next
End Sub
End Module
However, I still can't seem to get the correct calling for a VB Script/html page:
Set Test = CreateObject("Test.Accupay")
Which returns the VB Script error "ActiveX Component can't create object: Test.Accupay or any other iteration of the parts of the name that I tried. I think part of this is that I don't understand how the creation of the project leads to the creation of the object in a com base environment like VB Script.
Fred
The answer to this problem is two fold: You must target the correct platform (X86) AND use the 32 bit version of regasm. Once I realized this was the issue, I was able to create the DLL and use it's functions in the Web Browser control without the active X warning. One example is I can now open the default browser (in this case, NOT IE/EDGE) from a link within the WB Control and another is to get the contents of a folder for further processing within the WB page.
I'm trying to automate Microfocus Rumba application through VB.Net. Due to some constraints, I can't use any of the macros/scripts features that are inbuilt in Rumba.
I came to know that ehlapi32.dll can be used to automate Rumba but I couldn't add ehlapi32.dll or WHLLAPI.dll as references to the .Net solution.
I couldn't create objects of "Microfocus.Rumba"/"Rumba.System"/"Rumba.Application" because of the error "Cannot create Activex component". I tried to resolve it by registering the dll using RegAsm.exe. But it says the Dll is not a valid .net assembly.
I've attached the error snapshots.
Error while adding the dlls in References section of the .Net solution
Cannot create ActiveX component error
Not a valid .Net assembly error
Note : I'm using MicroFocus Rumba Desktop 9.4.1
Any guidance is deeply appreciated.
Thanks.
WHLLAPI.DLL and EHLAPI32.dll are not an ActiveX com component (thus you can't register it with regsvr32, nor create a com interop to it by registering it with regasm), and it's not a .net assembly (thus you can't simply add a reference to it). It's just an 'old fashioned' call library. You need to declare it, then you can make calls to it (via P/Invoke, to be technical).
Something like (the simplest version):
Declare Sub hllapi Lib "EHLAPI32.dll" (lpwFunction As Int32, ByVal lpbyString As String, lpwLength As Int32, lpwReturnCode As Int32)
Then call it
Dim status as Int32
Call hllapi(1, "A", 1, status) ' Connect to Presentation Space A
You'll need to reference the HLLAPI documentation, multiple versions/instances of that documentation is available online, with examples (and it's mostly standard across vendors). One is https://docs.attachmate.com/extra/x-treme/apis/ehllapi.pdf
My company's main software package includes a hefty configuration library which loads on startup. This config library includes some mandatory settings which, if not supplied (via command line arguments), cause the entire application to exit.
This has never been an issue for our users, who launch the software via scripts which have the needed command line arguments supplied automatically. But sometimes when debugging our software we developers forget to specify the necessary arguments in Visual Studio's debug options; it's then very annoying to be greeted with the message Config specification invalid -- missing required parameters X, Y, and Z -- shutting down (I'm paraphrasing, of course).
It's not really a big deal, just an annoyance. Still, I felt it worthwhile to throw together a little form to make this process a little less painful; it notifies the user which parameters are missing and allows him/her to specify values for those parameters directly on the form, without having to restart the application.
My intentions were good (I think?), but it seems I can't get this solution to actually work. The problem is that after I've launched our software with missing settings, the form pops up and prompts me as expected; but after I've entered the required parameters and it's time for the application to "really" start, I get this InvalidOperationException:
SetCompatibleTextRenderingDefault must
be called before the first
IWin32Window object is created in the
application.
I think I understand what's going on here: the VB.NET project I'm working on is doing something like this "behind the scenes"*:
Sub Main()
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
Application.Run(New MainForm)
End Sub
That call to SetCompatibleTextRenderingDefault is, apparently, throwing an exception because a form was already created and displayed prior to its execution.
Is there any way around this? Is there perhaps a more "proper" solution to this problem that I'm not thinking of (i.e., should I not be trying to collect user input via a form at all)?
*This is a best guess based on what I've seen in C# WinForms projects. Strangely, unless I'm missing something, it seems that VB.NET WinForms projects completely hide this from the developer.
Do make sure that you have the application framework option turned off and Sub Main selected as the starting method. Make it look similar to this:
Sub Main(ByVal args() As String)
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
If args.Length = 0 Then
Using dlg As New OptionsDialog
If dlg.ShowDialog <> DialogResult.OK Then Return
'' Use dlg result...
End Using
End If
Application.Run(New MainForm)
End Sub
Perhaps you could use the static Debugger.IsAttached (or even a #DEBUG directive) in your program's "main" function that feeds in some input file (say an XML file) into your parsed args collection instead?
I am currently refactoring an application that prints its status to the console window. At the moment I am doing something like this:
Console.Write("Print some status.....")
//some code
Console.WriteLine("Done!")
Now while this works fine, all the logic is hidden between console.writelines and I find makes it very hard to read.
I don't know if there is a better way of doing this, but I just wanted to ask and see if anyone has come up with a better/more clean way of print application status to the console.
Any ideas?
Take a look at Log4Net, it handles everything, but might be an overkill for your app, no idea. However knowing Log4Net will likely help you down the road someday so maybe this is a good chance too learn it.
I second using Log4Net. It is pretty easy to use it without invoking the difficult parts - just do the following:
In your applications Main() method, call
log4net.Config.BasicConfigurator.Configure(new log4net.Appender.ConsoleAppender());
That sets up a basic Console logger that logs all messages to stdout.
In the class that needs logging, create a new ILog like so:
private static readonly log4net.ILog log = log4net.LogManager.GetLogger(typeof (MyClass));
Then in the method that needs logging, call
log.Debug("Print Some status ...");
Once you have all of this set up and working. look through the Log4Net documentation on how to set up more useful logging. You can do a lot of different types of logging without changing the logging calls in your code at all.
Why not use a Logger object that write errors into a text file? You could come with some "priority" error messages such as: Logger.print(new priority("important"), "blabla");
This way, you could find in your file the exact time and all the message you want.
If you absolutely want the console, you could use the priority on the console.. so it would only prints what you tell the logger to print, such as network error, etc..
We have a web service solution in VB .Net 2005 that we have started getting an error in. We provide an interface like the following:
Public Interface IBatchTrackerService
Function InsertBatchTracker(ByVal BatchTrackerObject As BatchTracker, ByRef errorNum As Integer, ByRef errorMsg As String) As Integer
End Interface
In our class we implement this interface with the following code.
Public Class BatchTrackerService
Implements IBatchTrackerService
Public Function InsertBatchTracker(ByVal BatchTrackerObject As BusinessObjects.BatchTracker, ByRef errorNum As Integer, ByRef errorMsg As String) As Integer Implements IBatchTrackerService.InsertBatchTracker
'Some code here'
End Function
End Class
This code was working properly but has now started causing errors. The error we receive is:
Class 'BatchTrackerService' must implement 'Function InsertBatchTracker(BatchTrackerObject As BusinessObjects.BatchTracker, ByRef errorNum As Integer, ByRef errorMsg As String) As Integer' for interface 'IBatchTrackerService'.
The odd thing is that the project compiles correctly, but shows many of these errors after the compile is finished.
We recently installed Panda as our virus protection which caused a different error that I found the solution here for.
Any help would be greatly appreciated.
Thank you.
Updated 4/21/2009 at 11:50
Both the interface and the implementation are within the same project in the solution.
Updated 4/22/2009 at 08:16
I tried removing the BusinessObjects identifier from in front of the BatchTracker type but I still get the same thing. This is just one example of what has happened throughout the entire solution. Every implementation in this BatchTrackerService is flagged as an error, plus there are several other services that have almost every implementation flagged as an error as well. But somehow the project builds successfully, and yes, it runs properly!
As for BusinessObjects, it contains many of the classes we use as parameters and it is simply another project within this solution. We do not reference any external assemblies to provide these classes to BusinessObjects.
Updated 4/22/2009 at 08:24
The last thing I noticed was that any function/procedure that doesn't use a 'BusinessObjects' class as a parameter, but simply uses strings, integers, etc is not flagged as an error.
Updated 4/22/2009 at 09:50
I tried reverting back to a previous version and I was able to compile and the error count stayed at zero. I narrowed it down to a check-in of one of the project files where the reference to BusinessObjects was slightly changed. I reverted just this project file and everything compiles fine now. Thanks to everyone for leading me in the right direction.
It sounds like you're loading up a different version of the assembly that contains your interface in the web service and in the client, causing the client to reject the signature implemented by the web interface. Ensure that the versions are the same and, if necessary, strong-sign the assembly.
Your interface specifies that the "BatchTrackerObject" parameter be of type "BatchTracker" but your implementation uses type "BusinessObjects.BatchTracker". Try removing the "BusinessObjects." qualifier from your implementation.
Do multiple assemblies provide classes within the BusinessObjects namespace?